
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%ルール)

[DevOps Research and Assessment（DORA）](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling)チームが実施した 6 年間の研究から確立されたソフトウェア開発チームのパフォーマンスを示す 以下の4 つの指標のこと。

- **デプロイの頻度** - 組織による正常な本番環境へのリリースの頻度
- **変更のリードタイム** - commit から本番環境稼働までの所要時間
- **変更障害率** - デプロイが原因で本番環境で障害が発生する割合（%）
- **サービス復元時間** - 組織が本番環境での障害から回復するのにかかる時間

参考
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

Four_Keys

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

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

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

Attribute_Component_Capability


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

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

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

四次元主義


そのコンポーネントに障害が発生したらその障害がシステム全体に波及してしまう様なコンポーネントのこと。

Single Point Of Failureで略してSPOFとも言う。

システムを[グラフ理論](/wiki/グラフ理論)の[連結グラフ](/wiki/連結グラフ)だと思うと、単一障害点は[切断点](/wiki/切断点)であり、システム全体の[連結度](/wiki/連結度)は1である。

単一障害点


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

なんかあんまり美味しくない
ほげほげマウンテンはあんまり好きじゃ無いのかもしれない
苦味が薄めな感じ

クリスタルマウンテン


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

頂点


[機械学習](/wiki/機械学習)において入力層でも出力層でもないやつ

中間層

[サトシナカモト](/wiki/サトシナカモト)によって公開された以下の論文の仕組みによって分散的に運用されている世界で最初の[暗号通貨](/wiki/暗号通貨)。

https://bitcoin.org/bitcoin.pdf

論文の日本語訳

https://www.kk-kernel.co.jp/qgis/HALTAK/FEBupload/nakamotosatoshi-paper.pdf

ざっくり言えば「誰が誰にいくら渡した」という事実が記録された台帳データを、[プルーフオブワーク](/wiki/プルーフオブワーク)を付けて[ブロックチェーン](/wiki/ブロックチェーン)として繋げて記録することで、最も長いチェーンを信頼すれば[ビザンチン合意](/wiki/ビザンチン合意)ができる、という仕組み。

[チューリング完全](/wiki/チューリング完全)ではない等の欠点はあるが、一応簡易なスクリプトが使えるため、[スマートコントラクト](/wiki/スマートコントラクト)も作れるらしい。

この動画がわかりやすすぎた。

https://youtu.be/o-xhOBn4S60


Bitcoin


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

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

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

[万能チューリングマシン](/wiki/万能チューリングマシン)と同じ計算能力を持つこと。

チューリング完全

[ブロックチェーン](/wiki/ブロックチェーン)を用いた[暗号通貨](/wiki/暗号通貨)では、最も長いチェーンが有効とされる。

したがって、その分散ネットワークの全参加者のうち51%の信頼を獲得すれば、1人で最も長いチェーンを繋げることができる。これはつまり自由に台帳に取引履歴を書き込めるということで、そうなったら[暗号通貨](/wiki/暗号通貨)は終わる。

例えば[プルーフオブワーク](/wiki/プルーフオブワーク)では51%の計算リソースが必要で、[プルーフオブステーク](/wiki/プルーフオブステーク)では51%の[暗号通貨](/wiki/暗号通貨)が必要である。

[Bitcoin](/wiki/Bitcoin)等の規模が大きいネットワークでは攻撃はかなり難しいが、規模が小さい[暗号通貨](/wiki/暗号通貨)では実際に起こっている。

実例

https://coinpost.jp/?p=175687

51%攻撃

以下の様にプログラミングすること

- 問題を小さな塊に分解し、それらを縫い合わせる  
- 最初に実装してしまうと全体が見えなくなる

対義語は[アウトサイドインプログラミング](/wiki/アウトサイドインプログラミング)

https://www.oreilly.co.jp/books/9784873118864/

インサイドアウトプログラミング


可能な限りチームメンバーに仕事を移譲し、自身はチームメンバーが円滑に仕事をすることができるように仕えるというやり方



サーバントリーダーシップ


[Bitcoin](/wiki/Bitcoin)の論文を公開した人物。匿名であり誰なのかはわかっていない。

サトシナカモト

<p><a href="/wiki/%E6%BD%9C%E5%9C%A8%E5%A4%89%E6%95%B0">潜在変数</a>がある空間</p>


潜在空間