[SRE](/wiki/SRE)において、[SLO](/wiki/SLO)と現在の[SLI](/wiki/SLI)の値の差のこと。
この分だけ品質を下げられるということなので、その余剰資産を使って新機能の開発などのリスクを取ることができる。

エラーバジェット

[SRE](/wiki/SRE)において、Service Level Objectiveの略で、サービスの質を図る指標の目標値こと。

正常応答率99%を目指そう！と言った時、正常応答率を99%というのがSLO。

[SRE](/wiki/SRE)においては[トイル](/wiki/トイル)は50%以下を目指すルールがある。

50%ルール


鉄クロム線を石英管内にフィラメントとして設置したヒーターのこと。
値段は一番安い。
電気代が比較的高めだが、[ハロゲンヒーター](/wiki/ハロゲンヒーター)よりも少し安い。
一方で[ハロゲンヒーター](/wiki/ハロゲンヒーター)よりも暖かくない。

石英管ヒーター

裏切り者がいるかもしれない時に、どのように分散的に合意するかという問題。

転じて、間違う可能性のある分散システム上でどのようにデータに合意するか、という問題の基本的なバージョンと考えられる。

かの有名なLamport先生を含む3人が1980年の論文で合意問題として定式化したらしい。

https://dl.acm.org/doi/10.1145/322186.322188

最初の解決策も1982年にLamport先生たちが論文を出した。

https://dl.acm.org/doi/10.1145/357172.357176

この問題は裏切り者が1/3以上いる場合は解決出来ないことが知られている。

この合意が取れるシステムはビザンチン障害耐性 (Byzantine Fault Tolerance) があると言う。

分散システムの問題なので[暗号通貨](/wiki/暗号通貨)でもよく語られる問題である。

ビザンチン合意


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
ちょっと味薄めかも？

コロンビアスプレモ


https://en.wikipedia.org/wiki/Four-dimensionalism

時間的に連続なことが重要だから、三次元的に全く異なっている物体でも連続してるんじゃね？的な考え

[テセウスの船](/wiki/テセウスの船)とか[スワンプマン](/wiki/スワンプマン)の解決策

四次元主義


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

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

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

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


Link_Your_Thinking


[グラフ理論](/wiki/グラフ理論)における[グラフ](/wiki/グラフ)の定義から、[辺](/wiki/辺)の集合ではない方の集合。

頂点

[Bitcoin](/wiki/Bitcoin)に代表される、[ブロックチェーン](/wiki/ブロックチェーン)を用いた分散台帳に記載されたデータ残高のこと。

2023年1月時点の上位2位から10位は以下。

- [Ethereum](/wiki/Ethereum)
- [Tether](/wiki/Tether)
- [BNB](/wiki/BNB)
- [XRP](/wiki/XRP)
- [USB_Coin](/wiki/USB_Coin)
- [Binance_USD](/wiki/Binance_USD)
- [Cardano](/wiki/Cardano)
- [Dogecoin](/wiki/Dogecoin)
- [Polygon](/wiki/Polygon)

暗号通貨


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

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

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

[Rollup](/wiki/Rollup)手法の一つ。楽観的ロールアップとも呼ばれ、不正なブロックがめったに生成されないという前提の元、不正なブロックがあった場合には後から検証でブロックする方針。

Optimistic_Rollup


モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していくためのやり方のうちの一つで、以下の様な手法。

- まるっと別アプリケーションとしてコピーして立て、それぞれ1部の機能しか使っていない状態にする。  
- その後、不要な機能をリファクタリングによって削除していく。

戦術的フォーク

カーボンを使ったヒーターのこと。
電気代が[ハロゲンヒーター](/wiki/ハロゲンヒーター)より安く、遠赤外線が2倍出るため電力効率に優れる。

カーボンヒーター


[連結グラフ](/wiki/連結グラフ)ではない[グラフ](/wiki/グラフ)のこと。

非連結グラフ

<p><a href="/wiki/%E6%9A%97%E5%8F%B7%E9%80%9A%E8%B2%A8">暗号通貨</a>のうち、法定通貨と1:1での交換ができるもののことを言う。</p>
<p>運営会社が保証したり、<a href="/wiki/%E3%82%A2%E3%83%BC%E3%83%93%E3%83%88%E3%83%A9%E3%83%BC%E3%82%B8">アービトラージ</a>が起こる仕組みを作ってシステマチックに保証したりしている。</p>


ステーブルコイン