Site Reliability Engineering勉強会メモ
先週の木曜日にヒカラボ主催の
Site Reliability Engineeringの勉強会に参加してきました。
それなりに感じることもあったため、
内容をまとめて書こうと思っていたのですが
日々の雑事に流されてそのままになってしまいそうなので
まずは当日とったメモと雑感だけでもアップします。
おおむね、SRE本の内容紹介が主な内容でした。
（講演してくださったのが日本語版の訳者の方だったので）
話を聞いて特に強く残った点は
・個人の技量よりもチームとしての仕組みづくりの重要性
・「無駄な作業」というものをいかに言葉で定義するか（SREでいうところのトイル）
・最初から完璧なものはできない（Tryal and errorの精神）
といったあたり。
これらを日々の業務に生かしていければと思います。
以下当日とったメモ
■The SRE Book
海外ではSREの原点、バイブルと言われている
日本語版ではサブタイトルを変更
技術論より組織論の方が面白いため、日本人の先入観を考慮
エンジニア”チーム”の話
（技術の蓄積もあるが）組織としての考え方が果たしている役割が大きい
■SREが日本でも続々
メルカリ、スマートニュース、サイボウズ
特に運用系の仕事に関して日本でも広がってきている
■（余談）SREの皆さんの仕事っぷり
GoogleDocsのヘビーな話
必要なドキュメントを非常に手早く、しかも適切な集計・自動化を施して作成
いわゆるOffice系ツールの活用能力もとても大事
ちなみに最終の構成はdropboxでした・・・（PDF共同編集機能がある）
■（余談）三人称単数のThey
Theyが単数形として使われているケースがある
Gender Neutralな表現として、性別を持たない「人」をあらわす代名詞としてTheyが使われる世になっているとのこと
（シリコンバレーでは特に人事評価などに関わるドキュメントでは予断を挟まないために性別不明にする流れ）
■Site Reliability Engineerとは?
SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるもの
ソフトウェアエンジニアリングの発想で運用する
基本的には運用サイド（DevOpsのOps）の職種
スキルとして、インフラに加えてプログラミングが必須
・Googleの開発職に要求されるプログラミングスキルの８～９割が必要
仕事は大きく分けて運用業務（オンコールなど））と「改善」のエンジニアリング
サービスごとに担当はあるものの、SRE自体は全社横断的な組織
Googleのインフラストラクチャの上に乗る（開発とのインターフェース）
■SREの原則
・信頼性にフォーカスを置く
・ソフトウェアエンジニアリングによって運用を自動化、スケールできるように
・手作業→自動化→自律化（トラブルがあったときにシステムが判断して対応する）
・SREチームの規模はサービスの規模に比例してはならない（複雑さには影響を受ける）
・「トイル」（手作業でやっているつまらない仕事）の撲滅
・英雄的な献身に頼るのではなく、組織としての仕組みづくりを重視する
■トイルってなんだ（苦役）
・プロダクションサービスを動作させることに関係する作業で
・手作業で繰り返しが行われ
・自動化することが可能であり
・戦術的で長期的な価値を持たず
・作業量がサービスの成長に比例する
といった傾向を持つもの
■トイルの撲滅
たとえばサーバーの稼働状況のモニタリング
・メトリクスの生成、収集、集計といったことは徹底して自動化する
・その自動化のための「開発」作業は（50％ルールに守られて）積極的に行う
・Googleの場合、サーバーにはすべて
最初から完成度の高い仕組みを作ったりはできない。
自動化のメリットは「複利」
自動化してトイルを減らせば空いた時間でさらに別のトイルを減らせる
■速度と信頼性、そしてデータに基づく業務判断
会議室にいる一番給料の多い人の意見に従ってはいけない
ここでの「速度」は新しい機能やペースを投入するペースのこと
信頼性は主にSLO（Service Level Objective)のこと
開発者は速度を、運用者は信頼性を重視する傾向がある
新機能をリリースしたい 対 動いているものは変更したくない
計測されたデータに基づく業務判断
・エラーバジェット
・50％ルール
（あくまでGoogleの例。肝心なのは
・品質を示すデータの定義
・定義されたデータの計測
■SLI/SLO/SLA
SLI（サービスレベル指標 計測するデータの定義
SLO（サービスレベル目標 SLIに対して設定された社内的な目標値
（守れなかった場合に金銭のやり取りが発生）
SLOとエラーバジェット
エラーバジェット＝１－SLO（googleの場合は四半期でデータを計測）
エラーバジェットが残っている限り新機能をリリースできる（業務判断）
エラーバジェットが無くなった場合、リセットがかかるまで新機能のリリースは禁止
データに基づいて業務判断を行うことをルール化することで、
開発チームとSREチームが同じ方向を向いて業務に当たれるようにする
■１００％は目指さない
この場合、0.009％のためのコストは無駄
サービスの性格に応じたSLOの定義が非常に重要（Ex：ゲームとビジネス用途と人命にかかわる用途）
■50％ルール
SREはその作業時間の50％以上をエンジニアリング業務にあてないといけない
SREが運用業務にあてる時間が50％を超えた場合、開発チームがSREの支援に時間を充てる
■SRE book内の技術の話
「魔法」の話はSRE bookにはあまり出てこない
Googleのインフラがなくてもできる内容
ソフトウェアでコントロールできる範囲の話であれば学べることはたくさんある
ただし統計的な話が多いのが特徴的
→規模が大きくなると障害も統計確率的に扱わざるを得ない
モニタリングの話→書籍『Practical Monitoring』が面白い（未訳）
■計測と改善の仕組みづくり
・必要なメトリクスを得るための仕組みをインフラに作りこむ
・収集したメトリクスをモニタリングするための仕組みを作りこむ
・pythonが使えればマネできることはある
■SREの採用は大変
開発エンジニアのスキルの80％～90％、加えてインフラ知識が必要
基本的に需要に対して供給不足
Googleの場合、SREという「人」ではなくSREのノウハウを詰め込んだライブラリを使ってもらうという考えにシフト中？
■教育とオンコール
・オンコール対応になることはキャリアの１つのマイルストーン
・そこに至るまでの教育システムもきちんと整備する
「先人の谷に突き落とす」真似はしない
まずは過去のドキュメントやポストモーテム（トラブル報告書）の見直し
そしてベテランオンコールの「シャドウ」
その後オンコールとして独り立ち
■障害対応とトレーニング
・年一度、全社的な障害対応のトレーニング
・「たまにしかやらないことは身につかない」ことを受け入れる
・障害対応時の手順を日常業務に組み込んでおく
・できないことを精神論でかたづけない
・「ヒーロー」に依存しない
Ex：ネットフリックスのケイオスモンキー
→常に障害対応をしていればどんな障害にも対応できる、という理屈
■人事評価はどうやっているのか？（SRE Bookに出てこない）
■まとめ
SREの考え方は、技術的にはボトムアップで取り入れられることがたくさんある
ただし組織論的にはある程度トップダウンでないと導入しにくいところもある
