SRE サイトリライアビリティエンジニアリング 1章まとめ

最近SRE本を読み出しました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

内容が濃いし、ページ数も多いのでSlackのThreadにまとめながら読んでおります。

社内の人から反応をもらえたりして良い感じです。

上記のように箇条書きでざっくりまとめたものをブログに貼って備忘録にしたいと思います、読み進める上で誰かの参考になると幸いです。

1章 イントロダクション

• 以前は巨大なシステムを保守する人（ops）と開発する人（dev）で組織を分けていたが、コスト面やコミュニケーションなどでリスクが大きかった

• GoogleのSREチームではソフトウェアエンジニアを採用することに注力し、シスアド（管理者）が手作業でやっていたこともシステム化させた

• SREのチーム編成は50~60%がソフトウェアエンジニアであり、残りの40%がソフトウェアエンジニアの要項を85~99%を満たしつつ更にUNIXシステムとネットワーキングなどの知識を持ったエンジニアである

• 結果手作業を自動化するスキルセットを持ち、それを実行することをいとわないチームができた

• サービスの拡大に伴う運用の負荷を抑えるには、コードを書かなければならない。GoogleのSREチームでは運用業務の上限を50%にし、残りの時間を開発を行うためのものとした。超過した時間の文のタスクは開発チームへと差し戻す

• このルールを実行するには計測をする必要があり、これができれば開発ができていないチームの習慣を変えることができる

• GoogleのSREチームのアプローチには多くのメリットがある

• 直接コードの修正を行うので、素早い変更を広く受け入れることが可能であり、開発/運用の分断を回避し、開発チームの改善も行う。更には開発とSREチームの異動も用意なので相互にトレーニングも可能である

• 課題は人材の採用で、高いスキルセットが必要な上にユニークな業種なので取れる人は少ない

• SREの伝統的ではないアプローチにはマネージメント層のサポートが不可欠

• SREの基本的な責任はどのチームでも共通で、主にサービスの可用性・レイテンシ・パフォーマンス・効率性・変更管理・モニタリング・緊急対応・キャパシティプランニングである

• SREは運用と開発の対立をエラーバジェットの導入を行うことで解決をした。

• エラーバジェットとは100%の信頼を目標とすることは基本的にいかなる場合にも間違っているという所見から生じたものである。可用性のターゲットを1から引いたもので（可用性が99.99%は0.01%が利用できないということになる）計算し、許容する0.01%をこのプロダクトのエラーバジェット（予算）という

• SREと開発者は機能のリリース速度の最大化のためにエラーバジェットを使うことを目標にする。障害は悪いことではなく、SREは障害をゼロにすることを目標にするのではなく、開発者と共に障害をコントロールするようになる

• モニタリングは健全性と可用性の追跡のための主要な手段の一つであるり、方針は十分に検討する必要がある。

• これまで一般的だったモニタリングのアプローチである、しきい値を超えた際にアラートを発するというものは効果的なソリューションではない。なぜなら人間がアラートを読み、アクションが必要化を判断しなければならないからである

• アラートの領域のどの部分をとっても人間の解釈は必要であってはならない。代わりにソフトウェアが解釈を行い、人間のアクションが必要な時にのみ通知を受けとるようになっているべきである

• 効果的なモニタリングの出力は3つの種類がある

  • アラート：即座にアクションが必要であることを知らせる
  • チケット：システムが対応できないためアクションが必要であるが、即座ではない
  • ロギング：アクションは必要でなく、見る必要も無い。何かが起きた時に読むもの。

• 信頼性は平均故障時間（MTTF）と、平均修復時間（MTTR）の関数である、人が関わればレイテンシが生じるため、障害が多くても人間の介入を必要とする事態を避けていれば高い可用性を持つことになる

• 人間が関わる場合もベストプラクティスを考えておき、手順書にまとめることで「即興で行く」方針よりMTTRは3倍の改善が見られた

• GoogleのSREはオンコール手順書を使い、練習も行う

• SREは70%の障害は動作中のシステムの変更によって生じていることを発見した。この領域におけるベストプラクティスは、漸進的なロールアウト・高速かつ正確な問題の検出・問題時の安全なロールバックを自動化することである

• これらのプラクティスから人手を除外することで、慣れからの軽視、不注意といった問題を回避し、リリースの速度と安全性が高まる

• 需要予測とキャパシティプランニングは予想されている未来の需要に対して必要な可用性を提供できる十分なキャパシティと冗長性を保証することである

• 特別な概念では無いが、これを確認する手順を踏まないサービスやチームが多い

• キャパシティプランニングでは自然な成長と突発的な成長の双方を考慮に入れておくべきである

• キャパシティプランニングにはいくつかのステップが必要である。

  • 自然な需要の正確な予測
  • 需要予測に突発的な需要の発生源を織り込む
  • 計算リソースのキャパシティ（サーバのスペック）とサービスのキャパシティ把握のための定期的な負荷テスト

• プロビジョニング（必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと）は、変更管理とキャパシティプランニングの双方の組み合わせである。キャパシティは高価なので、プロビジョニングは必要な時にのみ正確にすばやく行うべきである。さもないと必要な時にキャパシティが活用できなくなる

• 大抵の場合キャパシティの追加には新インスタンスの立ち上げが必要になり、既存システムをかなり変更する必要がありリスクが高い

• リソースの効率的な活用はサービスで費用を考えるには重要で、最終的にプロビジョニングをコントロールするSREは利用率に関係する仕事にも携わらなければならない

• リソースの負荷は需要・キャパシティ・ソフトウェアの効率性によって決まり、SREはこれらすべてに関わる。そしてこの3つの要素はサービスの効率性の大部分を占める

• SREと開発者はパフォーマンス改善のためにモニタリングと改修に務めなければならず、キャパシティを追加して効率を改善する

• SREは大規模かつ複雑なサービスの管理においてこれまでの業界のベストプラクティスからは逸脱している。一連の指針・プラクティス・動機づけ・ソフトウェアエンジニアリングという広大な領域の中の注力分野となった

次の章

www.te-nu.com