[SRE](/wiki/SRE)において繰り返しで何も生み出さない作業のこと。

トイルを削減していき人が運用できる状態に保つことがSREの目標の一つ。

トイル


Site Reliability Engineeringの略で運用と開発のバランスをとって信頼性を担保していく方法論のこと。

[DevOps](/wiki/DevOps)の実装とも言われる。

[Google](/wiki/Google)が提唱したり[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)で触れられたりしている。

基本的な用語
- [SLI](/wiki/SLI)
- [SLO](/wiki/SLO)
- [SLA](/wiki/SLA)
- [エラーバジェット](/wiki/エラーバジェット)
- [トイル](/wiki/トイル)
- [オンコール](/wiki/オンコール)
- [50%ルール](/wiki/50%ルール)

[Ethereum](/wiki/Ethereum)の[L2ソリューション](/wiki/L2ソリューション)の一つ。

[Optimistic_Rollup](/wiki/Optimistic_Rollup)を採用したもの。

Optimism


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

マイクロサービスの粒度を大きくするか？小さくするか？もトレードオフである。  
  
粒度を小さくする要因としては以下のようなものがある。  
  
- サービスの範囲と機能  
  - 凝集性が高い状態になっているか？  
- コード変動率  
  - 一部のコードだけ変更頻度が高くないか？  
- スケーラビリティとスループット  
  - 一部だけスケールする必要があるか？  
- 耐障害性  
  - 一部の故障で全体が故障してしまわないか？  
- セキュリティ  
  - 一部だけ高いセキュリティが必要か？  
- 拡張性  
  - どの程度拡張されるか？  
  
粒度を大きくする要因としては以下のようなものがある。  
  
- トランザクション  
  - サービスをまたいだトランザクションが必要か？  
- ワークフローとコレオグラフィ  
  - サービス同士がやりとりする必要はあるか？  
- 共有コード  
  - サービス同士がコード共有の必要はあるか？  
- データ関係  
  - データは分解できるか？

サービスの粒度に関するトレードオフ

分散コンピューティングにおける定理。

ノード間のデータ複製において、以下の3つを同時に満たすことはできない。
- 一貫性 (Consistency)
	- すべてのデータ読み込みにおいて、最新の書き込みデータもしくはエラーのどちらかを受け取る。
- 可用性 (Availability)
	- ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。[単一障害点](/wiki/単一障害点)が存在しないことが必要。
- 分断耐性 (Partition-tolerance)
	- システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのようなネットワーク設計は[単一障害点](/wiki/単一障害点)をもつことになり、可用性が成立しない。


CAP定理


「そんなに好きならそいつにテスト付けときゃよかったのに」

ビヨンセルール


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

無難な味で結構使いやすい
安いし

モカシダモG4


メインの[暗号通貨](/wiki/暗号通貨)の[ブロックチェーン](/wiki/ブロックチェーン)と連携する目的で作られた別の[ブロックチェーン](/wiki/ブロックチェーン)のこと。

サイドチェーン


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

データベースを分けるか？分けないか？もトレードオフである。  
  
データを分解する要因として以下のようなものがある。  
  
- 変更制御  
  - カラムの変更等の影響が多岐にわたる  
- コネクション管理  
  - 1つのデータベースだけを使うとコネクション数の管理が難しい  
- スケーラビリティ  
  - コネクション数  
  - 容量  
  - スループット  
  - パフォーマンス  
- 耐障害性  
  - 1つのデータベースだけを使うとデータベースが単一障害点となってしまう  
- [アーキテクチャ量子](/wiki/アーキテクチャ量子)
  - 1つのデータベースだけを使うと1つの[アーキテクチャ量子](/wiki/アーキテクチャ量子)となってしまう (つまり独立してデプロイできない、等)  
- データベース種別の最適化  
  - 1つのデータベースだけを使うと1つの保存方法だけしか使えない (つまりデータ特性ごとに最適な選択肢が取れない)  
  
逆に、データを統合する要因としては以下のようなものがある。  
  
- データ関係  
  - 密結合な外部キー等があるか？  
- トランザクション  
  - 単一のトランザクション単位が必要か？  
  
モノリスなデータベースを分解するには5段階のプロセスを踏むと良い。  
  
1. 分析し、ドメインを特定する  
2. ドメインごとにテーブルを割り当て、移動する  
3. コネクションをドメインごとに分離する  
4. スキーマをそれぞれのデータベースに移動する  
5. コネクションを切り替える

業務データの分解に関するトレードオフ


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

あんまりだった
さすがに安定している味だったが

珈琲問屋冬のブレンド雪灯り

[暗号通貨](/wiki/暗号通貨)で非中央集権的かつ分散的に合意する方法。

主に[プルーフオブワーク](/wiki/プルーフオブワーク)や[プルーフオブステーク](/wiki/プルーフオブステーク)、もしくはそれらをベースに改良したものが使われている。

コンセンサスアルゴリズム

機械学習

契約を自動履行するシステムやプログラムのこと。

[Ethereum](/wiki/Ethereum)のような[暗号通貨](/wiki/暗号通貨)では[ブロックチェーン](/wiki/ブロックチェーン)に記された台帳上の金額を動かす[チューリング完全](/wiki/チューリング完全)なプログラムを実装できるため、それを用いてスマートコントラクトも実現されている。



スマートコントラクト


[Zettelkasten](/wiki/Zettelkasten)をデジタルでやるフレームワークらしい。

基本的には[Zettelkasten](/wiki/Zettelkasten)に従いつつ、以下の要素を加える。

- Map Of Contentsを作る。
	- ノートを繋ぐリンク集のようなノート。
	- ノートが100を超えたあたりから意識する。
- Homeノートを作る。

参考
https://www.linkingyourthinking.com/


Link_Your_Thinking

システムのテストすべき重要な箇所を洗い出す手法。

[Google](/wiki/Google)でも使われているらしい。

こちらを参照
https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki

Attribute_Component_Capability

<a href="/wiki/%E6%9A%97%E5%8F%B7%E9%80%9A%E8%B2%A8">暗号通貨</a>であり、<a href="/wiki/%E3%82%B9%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%82%B3%E3%82%A4%E3%83%B3">ステーブルコイン</a>の一種。
Tether Limited社が米ドルを担保に発行している。
シンボルはUSDT