- Site Reliability Enginieering
- 本番環境の信頼性を担保する人
つまりは運用チーム
ISO25010より
明示された時間帯で，明示された条件下に，システム，製品又は構成要素が明示された機能を実行する度合い。
つまりは、
- サイトが落ちてなくてちゃんと使える
- バグってない
信頼性を脅かすものの80%は新規機能の追加などの変更
つまり、触らぬ神に祟りなし
ビジネス要求
- 色々機能的に改善したい
- 停止せずに正常に動き続けてほしい
相反している！
- 極論すれば触らぬ神に祟りなしが障害ゼロへの最短ルート それでいいの？
- 稼働率99.999%->100% は ユーザーから見たら月に30秒の差 それ、マジで維持しないと死ぬんですか？ その0.001%のためにものすごいコストかかりますよね？
イノベーションと信頼性の適切なバランス
- システムと成長と安定の両立を目指す線を決める
- エラーバジェットが満タンになるまでは障害を起こしても良い
- 満タンになったら機能追加を諦めて安定を死守
- リスクをコントロールするようになる * リスクを取るべき時 * リスクを軽減するために時間を使う時
例1: フールプルーフ設計
- ある程度は防御的にしないとアホな操作でシステムダウン
- バリデーションを入れすぎるとユーザーはだれも使いたがらなくなる
例２: テストをどこまでやるか
- テストが不足していればプライバシーデータの漏洩、大障害でニュースに
- 臆病にテストばかりしていると商機を逃して結局誰にも使われない
- 機能が増えればサーバーが増える → デプロイ手順、扱うミドルウェア、見るべきメトリクス
- 負荷が増えればサーバーが増える → 何かが故障する率はどんどん上がる
どんどん人が必要になる
- OSレイヤーの知識
- ネットワークプレイヤー（特にL1〜L3）の知識
- 手作業でタスクをこなすことにすぐに飽きる
- 手作業を自動化するソフトウェアを書くエンジニアリングスキル
- 50%はいわゆる運用作業 チケット処理、監視アラート対応など
- 50%はエンジニアリングでなければならない アラートに対するリアクションの自動化、デプロイ効率化
増えゆく運用コストをエンジニアリングの力で押さえ込む
- 端的にいうと前向きな障害報告書
- 組織が学ぶために積極的に公開されるべきもので「サービスのどの部分をどうすれば改善できるのかを提起するもの」
- 人を非難しない
- 人を修正することはできないがシステムやプロセスを修正して、人が正しく判断できるようにする事はできる
- 開発
２つよく似ている
- 人手ではなく自動化に頼ること
- 運用タスクにエンジニアリングのプラクティス
SRE extends DevOps