1. SREへの期待
1.1. サイトの信頼性を保証しながら、サービスの拡大で作業量(開発、テスト、運用)が増えたとしても、自動化でカバーしてほしい
2. Googleの事例
2.1. 1.SRE組織と方針
2.1.1. 自動化できるにもかかわらず、手作業で行う運用作業にかける労働時間を「全体の50％まで」
2.1.2. 残りの時間で、自動化を目指すコーディングやサービスレベル向上に関連するプロジェクトに対応
2.1.3. 上記の割合で業務を進めなければ、SREへの期待(サービスが拡大しても作業量を増やさない)には応えられない
2.1.4. 四半期に一度のペースで、運用にかけた時間の棚卸しを行い、50%以上の時間を要しているのであれば、組織の編成、方針を再検討する必要がある
2.2. 2.サービスの可用性を下げず、開発速度の最大化を追求
2.2.1. サービスレベルの範囲内で開発(改善)速度の最大化に取り組む
2.2.2. 可用性を99.9%に設定しているのであれば、残りの0.1%がエラーバジェット(サービスを止めても良い時間の合計)となる
2.2.3. 商況を鑑みて、可用性が下がるリスクを理解した上で、メンテナンスや早期リリースに利用するなど エラーバジェットを超過しない範囲でできるだけサービス改善を行う
2.2.4. https://image.itmedia.co.jp/l/im/enterprise/articles/1803/19/l_ki_sre02.jpg
2.2.5. エラーバジェットを決めておくメリット
2.2.5.1. 「ビジネス上の事情によっては、可用性を下げてでもリリースを優先する」といった判断がしやすくなる
2.2.5.2. バジェットを使い切ることが目標になれば、素早く新技術の検証に取り組むモチベーションに
2.3. 3.サービスに異常が起きたときの早期検知
2.3.1. アーキテクチャで冗長化などを実現できたとしても、機器の故障による可用性の低下や、アプリケーション変更による性能劣化などは発生し得る
2.3.2. こうした異常を素早く検知するためには、可用性の数値以外にも、サービスのレイテンシ、エラー率、システムのリソースなどを、定期的に監視するシステムが必要
2.3.3. Googleの監視分類
2.3.3.1. アラート
2.3.3.1.1. サービスダウンの検知など、即時対応が必要なもの
2.3.3.2. チケット
2.3.3.2.1. 「リソース使用量の増加傾向」など、即時対応が必要ではない状況。この場合は、リソース増強などを検討して対処することになる
2.3.3.3. ロギング
2.3.3.3.1. 普段は確認する必要がなく、詳細の分析や追跡の際に利用する
2.3.3.4. https://image.itmedia.co.jp/l/im/enterprise/articles/1803/19/l_ki_sre03.jpg
2.4. 4.サービス異常時の早期復旧
2.4.1. Googleではサービス異常時の復旧も可能な限り自動化し、人為的なミスを防ごうとしているが、 全てを自動化するのは難しいため、障害対応をシミュレーションする取り組みを行っている
2.4.2. 具体的には、訓練用としてシステムの障害連絡を受けたら、疑似障害の対応を実施し、対応の振り返りを行う。
2.4.3. その際に早期復旧のためにやるべきだったことを確認することで、不足しているドキュメントがあれば作成し、自動化できる部分があれば対応するきっかけが得られる。
2.4.4. https://image.itmedia.co.jp/l/im/enterprise/articles/1803/19/l_ki_sre04.jpg
3. 参考記事： https://www.itmedia.co.jp/enterprise/articles/1803/19/news016.html
4. 以上の前提を踏まえて以下記事のような、どういった要件に対して どういった技術を使うかということを考えるべき https://infra-note.net/sre-engineer/
4.1. SLA、SLO
4.1.1. 監視ツール
4.1.1.1. Zabbix
4.1.1.2. Nagios
4.1.1.3. Datadog
4.2. 障害対応、リリース時間短縮
4.2.1. コンテナ
4.2.1.1. kubernetes
4.2.1.2. Docker
4.3. リソースの自動化 【AVC+ではある程度形になっている】
4.3.1. CI/CD
4.3.1.1. Jenkins
4.3.1.1.1. https://www.kagoya.jp/howto/it-glossary/develop/cicd/
4.4. インフラのコード化 【AVC+ではある程度形になっている】
4.4.1. laC
4.4.1.1. Ansible
4.4.1.1.1. https://proengineer.internous.co.jp/content/columnfeature/20537
4.4.1.2. Terraform