SRE サイトアビリティエンジニアを読んで, 1

はじめに〜１章

SREの提唱者：Benjamin Treynor Sloss氏の言葉である（忘れずにメモしました）

願望は戦略にあらず。

結局のところ、SREって結局何？
SREと検索すると「Site Reliability Engineering」サイトの信頼性向上・・・・　云々とあるが

SREとは「ソフトウェアエンジニアが運用を設計したらどうなる？」という事

NewRelicさんのセミナーでこれを聞いてなるほどと思いました。
そう手法・方法のことを言っているですね、だからDevOpsの一部とも言えます。

著書にも下記のように定義されています。

SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるもの

SREに必要なスキルセット

・ソフトウェア開発に対する信念・適性
・ソフトウェアエンジニアであること
・サーバー（UNIXの内部知識）、ネットワーク（L1~L3）の知識があると良い

SREとして、特性を一番持った最初の人物は誰か？　

それはアポロ計画で働いていた、ソースコードを積んでる写真で有名なMargaret Hamiltonである ※SRE本によると

どんな人なのか、アポロ誘導コンピュータのソフトウェアを作成したりと、いろいろな逸話を聞きます。
Wikiだと分かりにくいので軽く知りたい人は下記が分かりやすい。（以前動画で観たのですが有料版でした）

岡田斗司夫の毎日ブロマガ「ロケットに宇宙飛行士って必要かな？ って思ってました」

https://www.youtube.com/watch?v=1GiYUXSBY28

今回のSRE本に書かれている逸話でも、あるプログラムを実行する重大なバグをドキュメント対応したが結局ミッション中に発生してしまった（マーガレットの機転により回避された）
マーガレットは事前に、修正するように提言していたのにもかかわらず起きてしまったのだ。

こういう状況はNASAレベルではなく良くある。
自分ごとだが、修正する必要性を何度も上司に確認をとり回避マニュアルを作成したが結局お客さんの意向で修正したこととかあった。。。。

SREの重要性がとても身に染みせるエピソードだった

SREの信条（掟）

信条とは、堅く信じて守る事柄である。
少し違うがこれだと理解しにくいので、掟（おきて）で良い気がします。
掟は８つあります。

その１：エンジニアリングへの継続的な注力の保守
その２：サービスのSLOを下回ることなく、変更の速度の最大化を追求する
その３：モニタリング
その４：緊急対応
その５：変更管理
その６：需要の予測とキャパシティプランニング
その７：プロビジョニング
その８：効率とパフォーマンス

「その１：エンジニアリングへの継続的な注力の保守」
→数値化（割合）することでソフトウェアの時間を確保
オンコールを減らし（1日２つまで）内部資料をしっかり書く

「その２：サービスのSLOを下回ることなく、変更の速度の最大化を追求する」
→プロダクトの利用方法の理解し、許容されるエラーバジェット内でのSLOを策定し、そのSLO内で費用対効果を考えたリリースする（障害をコントロールする）

「その３：モニタリング」
→人間の解釈がなく、人間がアクションするもの
アラート：即座に対応
チケット：後で対応
ロギング：診断・証拠に使う

「その４：緊急対応」
→なるべく人間が対応しないようにして、対応必要な場合は手順書を必ず用意する

「その５：変更管理」
→サービス障害は動作中のシステムで70%おきてたので
ロールアウト・問題検出・ロールバックなどを自動化する

「その６：需要の予測とキャパシティプランニング」
→未来に対しての、冗長性とキャパシティを提供する
・リードタイムを考えた正確な予測
・突発的な事象の検討
・定期的な負荷テスト（予測するな計測せよ！）

「その７：プロビジョニング」
→「その５」「その６」を同時にやらないといけなく、注意が必要

「その８：効率とパフォーマンス」
→サービス費用(効率)・パフォーマンス改善を検討しながらリソースの利用を検討する

メモ
ページャー：呼び出し　
ポストモーテム：想定外のインシデントが発生した後に書かれる内部向けの報告書
エラーバジェット：エラーに対する予算、損失可能な信頼性（超えてなければ、SREはまだ大丈夫だと落ち着ける）

参考資料
@tenkomaさんのツイート
ポストモーテムとは
エラーバジェットとは

感想

これだけまとめたのに、まだ数ページしか行ってないという濃厚な本です
頑張れたら、これ以降もまとめます