🚀 ニフティ’s Notion

• 運用は「システムをいかにうまく動作させるか」という答えがない問いが存在し、さらに運用チームをうまく運営する方法も取り組まれていない
• 運用はシステムを改善するためのものではないので、多くの場合にはコストがかかるだけとみなされてしまう（コストセンター）
• 価値のある改善は安定的な運用から発生し、それらは切り離せないものであるのではないか？という考え方からDevOpsおよびSREの考え方が生まれる。

• DevOpsは、IT 開発、運用、ネットワーキング、セキュリティのサイロを壊すために設計されたプラクティス、ガイドライン、文化の緩やかな集合
• DevOps のアプローチでは、組織全体を改善できるように 何かを(多くの場合、自動化することによって)改善し、結果を計測し、共有を行う
• DevOps、アジャイル、そして他の様々なビジネス及びソフトウェアのリエンジニアリングの手法はすべて、現代社会においてビジネスを行う最善の方法に関する一般的な世界観の例である
• ソフトウェア開発者がビジネスをするためにDevOpsは生まれた
  • SREはDevOpsの思想の実践であるので、DevOpsの背景をまずは理解する

• 運用チームと開発チームが別々になっている場合、サイロ化という現象が進む（それぞれのチームが縦割りで情報を持ち、情報共有がされない）
• 極端な知識のサイロ化は、多くのケースでビジネスに悪影響を及ぼすという事実がある
  • https://www.fastcompany.com/1839317/build-your-business-smash-your-silos
  • https://www.fastcompany.com/1837301/5-ways-process-killing-your-productivity

• アクシデントは個人の行動の結果ではなく、何かがおかしくなった時のための防護策の欠如によって起きる、と考える
  • 悪いインターフェースは、間違ったアクションを意図せず促進する
  • システム仕様に欠陥があれば、間違った環境が障害を起こしてしまう
  • モニタリングが壊れていたら、異常が生じても知ることができない
• アクシデントを避けるのではなく、リカバリーを早めるやり方を優先する

• 変化は小さく頻繁に起こすのが最善
• 現在では、月に1回計画を議論し、全ての変更を経験のある人物が検討する、というやり方は、バッドプラクティスだとわかっている。
  • この考えは現在広く採用されているアジャイル開発手法にも通じる
• 変更は確かにリスクを伴うが、変更を小さいものに分割する
  • 分割した小さな変更を頻繁にリリースするために、自動テストやCI/CDのような変更管理へのアプローチにつながる

• 変更を正しく管理するためには、ツールを活用することが不可欠
• ただし優れたツールだけではなく、上に述べたマインドがある文化も同時に組織にないと、DevOpsが提唱する新しい働き方は難しい
• 「文化は戦略に勝る」

• 目標の計測によって、起きていることを理解し、期待通りに状況が変更されていることを検証し、チーム間の合意のための会話を支える。
• これはビジネスでも運用でもどちらの文脈でも言える

• サイトリアイアビリティエンジニアリング（SRE）はGoogleのエンジニアリング担当バイスプレジデントのBen Treynor Slossが作った言葉(であり関連する仕事のロール)です
• DevOps を哲学と働き方へのアプローチと考えるなら、SRE は DevOps が掲げている哲学の一部を実施したものと言え、「DevOps エンジニア」よりも明確な仕事やロールの定義と言える
  • もともとSREはDevOpsを実装する役割を表すGoogle社内の用語
• GoogleのSREの歴史は、運用に重点を置いた先駆的なチームから生まれているが、Benがエンジニアリングの観点から問題を扱うように推進し直したことで、今のSREという役割と考え方が生まれている

SREが行うことは以下に定義する原理原則を実行する

• SREの基本的な信条は、運用をうまく行うのはソフトウェアの問題だということ
• SREは問題の解決のためにソフトウェアエンジニアリングのアプローチを用いる
  • 人間の気合いや根性ではなく、仕組みを改善したり自動化することによって問題を解決する
• これはビジネスの観点から、技術スタックを書き換えるまで、全てに適用される

• SREは100%の可用性を与えない
  • 100%可用性を与えようとするとサービスを改善しないでそのままにしておいた方が良いという判断になりやすく、新しい機能の開発や、ユーザーへのプロダクトの提供速度が制限され、コストが劇的に増大する
    • これは自分達がやろうとしている、ユーザーに価値を迅速に届けるという思想と反する
• プロダクトチームと SRE チームは適切な可用性のターゲットをサービスとそのユーザー ベースに対して選択し、サービスはその SLO に応じて管理される
  • 反対に言えば、SLOに余裕があるのであればリスクがあるリリースさえも許容される

• SREは、仮にマシンが求められる運用を実行 できる のであれば、多くの場合マシンが するべき だと信じている
  • そういった運用がないとは言わないが、それは最小化されるべき
• Googleの文脈において、手作業で繰り返し行われるようないわゆるトイルは仕事ではない
  • 多くの企業ではこのトイルこそが仕事とされている
• 機械ができる運用は機械にやらせるべきで、それ以外に使った時間こそがプロジェクトの作業に使われた時間と考える

• Googleで実践されているSREでは、トイルに費やすことができる時間に50%という上限を設けている
• これは問題に対して繰り返しトイルとして対応する（手作業で対応する）のではなく、エンジニアリングベースのアプローチを採るための明示的な宣言である
• 時間が経つと、SREのチームはサービスについて自動化できることをやり終えて、自動化できないことは残すことになる
• Googleの環境では、SREチームの作業において自動化できない作業（トイル）が支配的になってくると、50%の時間はサービス改善のために使うようになるか、異動して全く別のことをするようになる。

• SREによって信頼性が増大するが、実際にはプロダクト開発のアウトプットの改善の方が大きな利点をもたらす。
• SREが実践されると、平均修理時間（MTTR）が削減されるため、障害でエンジニアが時間を無駄にしたり、クリーンアップに集中する必要がなくなるため、結果的にプロダクト開発の速度向上がもたらされる
• SREは後になって問題が発見されるという望ましくない状態を改善し、会社全体としての利益を生み出すことを任されている

• プログラマーと運用者との間に厳格な境界を置くことは非生産的である
• 責任を分離したり、運用をコストセンターとして分類することは、パワーバランスの崩れや評価および給与の違いにもつながる
  • 運用と開発はどちらも必要なことであり、これは望ましい状態とは言えない
• 理想的には開発チームとSREチームはどちらもスタックの全体像を把握しているべきである
  • 開発と運用が役割分担はしていても、一枚岩の状態であるべき

• SREはGoogleにおけるDevOpsの実践であり、以下のような共通点と違いがある

• DevOps と SRE は、どちらも改善のためには変更が必要だという認識を受け入れる
• コラボレーションは、DevOps の作業の最前線であり中心である
  • これはチームベースのサイロからの脱却を促すことでもある
• 変更管理は、理想的には変更の大部分が自動的にテストされ、小さな連続的アクションであるべき
  • ビッグバンリリースのような大掛かりなリリースはせず、少しずつ頻繁に改善する
• 計測は、DevOps と SRE の作業において絶対的な鍵
  • SREにとって、サービス改善のために行うアクションを決定する上で、SLOが最も重要
  • 計測がなければSLOを決定することができない
• プロダクションサービスの管理という厳しい現実は、ときおり悪いことが起こること、そしてその理由を語らなければならない
  • SREではこれを語るためにポストモーテムを行う
• 究極的には、DevOps もしくは SRE の実施は包括的な行いである。どちらもチームや組織全体を、特定の方法で共に作業する営みをより良くすることを目指している。
  • DevOps と SRE のどちらにとっても、開発速度の改善が成果であるべき

• DevOpsはより広い哲学と文化について言及しており、運用の方法については詳細レベルでは語っていない
  • サービスの詳細な管理については規範を示さず、広い組織における障害の排除に集中する
• SREは相対的には狭く定義された責任を持ち、ビジネス全体よりもサービス志向である
  • SREはGoogleによるDevOpsの実装と言われるが、DevOpsの思想を実際にシステムの運用に具体化した方法がSREと考えられる
  • SREはシステムを効率的に動作させるという問題に対して、SLI/SLO・エラーバジェットなどを代表とする、主張の強いフレームワークを持ち込む

• ソフトウェアエンジニアリングにおいて運用とは難しい課題であり、開発と運用を両立させるためにDevOpsという考え方が近年実践されている
• SREはGoogleにおいて実践されているDevOpsであり、実際にシステムの運用に具体化した方法である
• SREは、SLI/SLO・エラーバジェットなどを代表とする、主張の強いフレームワークを持っており、明確な原理原則を実行する