2020年に、若干遅めですが以下のオライリー本は購入し、なんとなくSREはなんなのかを意識し始めました。

2020年段階で読み終えて、且つ、消化した感があるのは入門監視のみで、SRE本とワークブックは今のところ積読状態になっています。
今年はこの辺りのキャッチアップをしたいので、まず書籍を読む前に以下のチェックリストを自分なりに、読み解いて解釈してみようと思いました。
SRE チームの評価に役立つレベル別チェック リスト | Google Cloud Blog
調べた結果を記載します。

SREチームの評価に役立つレベル別チェックリストとは?

SRE の基本原則

SREの基本原則としてチェックリストには以下の3つが記載されています。

  • 何らかのサービス レベル目標（SLO）を決め（開発、事業部門の一部でない場合は、これらの部門のメンバーと共同で）、ほぼ毎月目標を達成していること

  • 非難を伴わない障害報告書を記録するカルチャーがあること

  • 本番環境におけるインシデントの管理プロセスが作られていること（これは全社的であることが望ましい）

3つの基本原則で気になったことを記載していきます。

サービスレベル目標(SLO)

サービスレベル目標(SLO)以外に、サービスレベル合意(SLA)もあります。
また、サービスレベル項目(SLI)というSLO、SLAとして設定する指標を示す言葉もあります。

SLOが毎月達成されているか確認するには？

何らかの手段で計測する必要があります。
計測の手段として、APMツールを使うということを思い浮かべました。
【ツール8選】APMツールとは？基本解説やおすすめツールをご紹介！ | QEEE
また、クラウドサービスではなく、オープンソースを使用することもできます。
OSSのおすすめ監視サーバ・監視ツール比較18選 | OSSでのシステム構築・デージーネット

非難を伴わない障害報告書とは?

これは、ポストモーテムのことかなと思います。ポストモーテムについては良い記事がたくさんあり、読むと勉強になります。

また、テンプレートが Google re:Work のページで公開されています。
SRE文脈以外でも使われる言葉、テンプレートなのかと思います。
- Google re:Work - ガイド: イノベーションが生まれる職場環境をつくる

インシデントの管理プロセスとは?

初級者チームのチェックリスト

初級者チームのチェックリストの内容は以下の通りです。 引用部がチェックリスト内容で、１項目ずつ補足説明、感想を記載します。

人員の配置転換と採用のプランがあり、予算が承認されていること

SREワークブックの20章に記載があります。
SRE人材のリソース計画、その予算が承認されているのかを確認する項目です。

「SREがない場合でも、SLOを使うことによってSREのプラクティスはできます。」の一文はSREチームがない組織で何かやってみようという気持ちを後押ししてくれます。

スタッフを配置したチームが何らかのサービスのオンコール サポートを担当するとともに、少なくともシステム運用の負荷の一部を担っていること

  • システム運用の負荷の一部を担うとは？

    システム運用作業を実施することに思いました。

  • オンコール

    アラートに対して受電し、エラーの内容確認を行う作業です。

リリース プロセス、サービスのセットアップとティアダウン（そして可能ならフェイルオーバー）のためのマニュアルを整備していること

SLO の一部としてカナリア リリースを評価していること

必要なときのためにロールバック メカニズムを用意していること（ただし、たとえばモバイル アプリケーションが関係するときは簡単ではないことが考慮されます）

完全でなくても、運用手順書（プレイブック / ランブック）があること

SREと名前がついていない運用保守チームでも手動、自動関わらず、運用手順書は必要です。

少なくとも年 1 回は理論的な（ロールプレイングによる）ディザスタ リカバリ テストを実施していること

以下が情報がまとまっていて参考になりました。

これだけでわかるディザスタリカバリガイド | ベリタス

SRE がプロジェクトの仕事を立案、実施していること（開発者の支持を必要としない運用負担軽減の取り組みなど、開発者から直接見えない部分でもかまいません）

プロジェクトの仕事の立案、実施ができるとは、自己組織化モードになっていることが理想に思いました。 エンジニアがリーダーになるためには. 前回に引き続き、今回はリーダーシップについて。読んだのは、翻訳者の島田さん（… | by Shinichiro OGAWA | なんとなく日記

定期的に（つまり毎週）インシデント対応手続きの訓練をする程度のオンコール

全くオンコールが発生しない状況が長く続くと、人の入れ替えが発生したりする場合、オンコールに対応できる人材がいなくなってしまいます。SREはSLOで100%の稼働率は目指していないのは、この訓練の意味もあるのかと思います。

SRE の統括責任者（つまり CTO）が審査、承認した SRE チーム憲章

SREではなくてもチーム憲章は必要です。

一瞬インセプションデッキが浮かびましたが、SREとしての話題を記載するにはSRE チーム憲章の方が適していると思います。

問題点や目標について議論し、情報を共有するための SRE と開発リーダーの定例会議

サービス単位にチームが分かれていたりすると、SREチームがサービスごとに存在する可能性があり、その間でのコミュニケーションも重要に思いました。

  • SREチームが複数ある場合、その複数チームが定例会議を行っている
  • サービスの開発チームとサービスのSREチームが定例会議を行っている

を観点に考えても良いように思いました。

開発と SRE の共同作業によるプロジェクトの立案、実施。SRE の貢献とプラスの効果が開発のリーダーにも見えていなければなりません

SREチーム自体の価値と、貢献を図るためのSLIを設定しないとまず、貢献とプラスの効果が可視化されません。まず最初にSREのプロセスのまず初めにやることで、SLO、SLIを定義するのはこの効果を可視化して、全員が納得して進めるためだと思いました。

チェックリストは以上です。

O’Reilly Japan - SRE サイトリライアビリティエンジニアリング、O’Reilly Japan - サイトリライアビリティワークブック ともに分厚い本なので、読むこと、理解することに時間がかかります。

実践時は、チェックリストを使って落下傘方式で学ぶことと、冷静に頭から書籍を読んで体系的に学ぶの両方で少しずつ学習できればと思います。 まずは業務との関連を意識するところからでしょうか。
以上です。

コメント

カテゴリー

最近の投稿