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

開発と運用を分けずに一緒にバランスをとっていい感じにしていこうぜというもの。

具体的な方法論としては[CI](/wiki/CI)や[CD](/wiki/CD)など。

実装として[SRE](/wiki/SRE)がある。

DevOps


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

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

[テセウスの船](/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/ソフトウェアアーキテクチャ・ハードパーツ)

[ハードパーツ](/wiki/ハードパーツ)としてのコントラクトの定義は以下である。  
  
> アーキテクチャの部品が情報や依存関係を伝えるために使用するフォーマット。  
  
コントラクトとして例えば以下の様なものがあり、トレードオフがある。  
  
- 堅い
  - 例
    - gRPC  
  - メリット
    - 型
    - バージョニング
    - 検証が用意
    - ドキュメント  
  - デメリット
    - 密結合  
- 緩い
  - 例
    - JSON
  - メリット
    - 疎結合
    - 進化しやすさ
  - デメリット
    - 型がない
    - コンシューマ駆動契約等の適応度関数が必要

帯域幅は無限だと思うな。

コントラクトに関するトレードオフ


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

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

モカシダモG4

https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K  

[見積もり](/wiki/見積もり)

ソフトウェア見積もり_人月の暗黙知を解き明かす


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

非連結グラフ

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

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



スマートコントラクト


[グラフ理論](/wiki/グラフ理論)における[グラフ](/wiki/グラフ)の定義から、[頂点](/wiki/頂点)の組の集合。


[ソフトウェア見積もり_人月の暗黙知を解き明かす](/wiki/ソフトウェア見積もり_人月の暗黙知を解き明かす)の内容が書かれている。

## 第1部 見積もりの考え方  
### 第1章 見積もりとは  
  
- 「見積もり」「ターゲット」「コミットメント」の違いを意識する  
  - 見積もり：そのままの意味  
    - 「この機能の実装は何人日」  
  - ターゲット：実現したいビジネス上の目標  
    - 「何日までにこの機能を提供したい」  
  - コミットメント：機能を一定のレベルで期日までに納品するという約束  
    - 「何日までにこの機能を提供します」  
- 見積もりと計画の違いを意識する  
  - 見積もりは正確性が重要  
  - 計画は結果が重要  
  - 偉い人にターゲットを達成するための計画を聞かれているのに見積もりを単に答えてはいけない  
    - 「このプロジェクトは何人月？期限は３ヶ月なんだ」  
    - 「見積もってみたところ５ヶ月かかります」  
    - 「ふざけるな！」  
  - 開発と期日どちらが優先かどうか尋ねる  
- 良い見積もりとは偉い人の意思決定に寄与する見積もりのこと  
  
### 第2章 見積もり能力のチェック  
  
- 直感で「90％確か」な見積もりは、実際には「30%確か」  
  - なので直感で90%とか言ってはいけない  
- 見積もりなんて幅があって当然。無理に狭めようとしない  
  
### 第3章 正確な見積もりの価値  
  
- 意図的に過小に見積もることはすべきではない  
  - 過大見積もりよりも深刻な被害が起きる  
  - では過大にすれば良いかというとそうでもなく、それなりに大きくしてあとは計画とコントロールで対処せよ  
  
### 第4章 見積もり誤差はなぜ起きる？  
  
- 見積もり期間を増やしても見積もりの不確実性は上がらない  
  - プロジェクト自体があやふやなのではどんなに頑張っても上がらない  
  - 見積もり期間を増やすのではなく、要件定義や設計を固めることでしか上がらない  
- 休暇、病欠、トレーニング、ミーティング等は必ず発生する。そのためのゆとりをもたせる  
- 開発者の見積もりはすでに必ず楽観的であるので削ってはいけない  
- 見積もりに「コントロールノブ」を持たせてはいけない  
  - コントロールノブとは見積もりに入れる主観的判断のこと  
  - 見積もりの客観性と共に正確性も落ちる  
- 即興の見積もりはしない  
  - たった15分の見積もりでさえもっと正確になる  
  
## 第2部 見積もりの技法の基礎  
  
### 第7章 数えて、計算して、判断する  
  
- できるときはまず何かを数える  
- 数えられない場合にのみ計算する  
- 計算すらしないのは最終手段  
  
### 第9章 専門家の判断  
  
- タスクで分解して見積もるときは長くても2日程度の粒度にする  
  
  
## 感想  
  
「技術者の見積もりは常に楽観的」というのはその通りだと思った。  
幅がある見積もりの中で最小の部分を提出する傾向があるような気がしているし、  
実際過小に見積もる圧力があるということも書かれていた。  
  
一方で、数えるだけの方がよほど正確に見積もれるというのは不思議だった。さすがにコード行数で数えるのはどうかと思うが。  
  
過去の開発にかかった工数と関連データの保存および可視化が出来ていないと不可能な手法ではあるので、これらの重要性はかなり高い。  
  
生産性向上とか言っておいて生産性を測る指標を可視化していないなんてことがザラにある状態では正確な見積もりなんて望めないということかもしれない。

見積もり


[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)の定義では

> コードの挙動を変えずに整理された内容に書き直すこと

である。

つまり、最も重要なのは自動テストである。自動テストがないと挙動が変わってないことが担保できないからである。

参考
https://qiita.com/miketako3/items/3085e225a35cdf89cd55

リファクタリング

<p>与えられた命題が真であることを、それ以外の情報を与えずに証明すること。</p>


ゼロ知識証明