この記事は、SRE Advent Calendar 2024 の24日目のエントリです。
はじめに
まず、組織の考えではなく、私個人の考えです。今後、社内でSREエンジニアを名乗ることになるかもしれないので、アドベントカレンダーを機に何をしようか考えてみました。
現在地
私の現状やSREの知識
インフラチームに所属しています。
「SREサイトリライアビリティエンジニアリング」はつまみ読み、
「SREサイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本」は読みました。
SREで検索するとよく出てくる（業務の）自動化についてはそれなりに経験がある一方、オブザーバビリティについてはこんな感じかな程度です。また、そもそも転職して間もないため、土台となる自社サービスや業界の知識をキャッチアップ中です。
チームの現状
ここ最近は開催されていないようですが（一段落ついた？）、定期的に勉強会（主な内容は自動化）を開催されていました。
運用業務や障害対応からこうしたほうがいいよね、こんなのあったらいいなと意見が出され、チーム内で揉んでタスクにし実践していますので、土壌はあると思っています。
また、開発チームとも関係は良好で、障害対応も一緒にあたっています。
何をするか考える
初めに、うちのチームは何に対して、どんな活動をして、どこを目指すのか、言語化/定めます。
次に、上層部とその内容で合意をとって業務にし、実践後、振り返ります。
1. サービスの現状分析
監視と運用作業の面から考えていきます。
監視では、サービスの主要な機能や現在の監視内容を洗い出し、それぞれ何を何のために監視しているか、理解も兼ねて整理します。また、過去の障害情報をあたってみて、傾向を探るのも良いかもしれないです。
運用作業では、定型業務や手間のかかるタスクをリストアップし、残っていれば過去の経緯もおさえておきたいです。
2. 目標の設定
おそらくSLI/SLOはないので、これを共通目標にします。
短期的（半年）、長期的（１年）な目標を考え、それに対して何をしていくかざっくりとした活動計画を作成します。
案としては、サービスの品質向上、コストの最適化（可視化と確認はある程度できている）、デプロイの自動化率を高めることが浮かんでいます。
3. インシデント管理プロセスの構築
ここはある程度出来ているので、チケット起票から解決までのスピードなどを継続的に改善していきます。
また、チーム外から何らかの要望が拾えるかもしれないので確認します。
4. 監視とアラートの改善
モニタリングツールは、現行のものを使用します。
1の結果をもとに、何をどんな目的で監視するのが良いか整理し（書籍から整理項目を定めてみるのもよさそう）、場合によってはメトリクスの監視を追加します。
特にユーザ体験をもとに、アクセスログやCPU/メモリの使用率、各コンポーネント間のレイテンシなどを紐づけて整理できたらと考えています。
具体的には、これがこうなったらサービス影響が出そうなので監視しようという障害からの観点ではなく、むしろ障害にはつながらないところで、より便利になったらいいなという観点です。
また、惰性や過去必要だったから設定したアラートもありそうなので、そういったノイズの多いアラートを削減したり、実際に対応が必要なアラートを絞り込んでいきたいです。
5. 定型業務の自動化
半自動化やスクリプトの自動化はそれなりにされていますが、まだまだ工数のかかる人手の作業はあります。そのため、自動化の候補を絞ってTerraformやAnsibleで自動化していきます。
なんなら他チームや依頼者をどんどん巻き込んで、所属チームではなく、依頼者が実行できる状態に持っていきたいです。
6. チーム内外への共有
所属チームでは週一で共有会を設けているので、形骸化させない、より実のあるものにしていきたいです。トピックがなければその週は開催しなくていいかも。
また、ドキュメント類はいうほど放置されていないけど、継続して整備/更新します。
チーム外への共有は、開発など身近で一緒に作業する他チームであれば関係あるタスク単位で共有しています。
それ以外や上層部との共有は、最初は上司が報告していればいいけど、いずれ自分達から報告する何らかの場を持っておきたいです。
7. 半年後・1年後の振り返り
何をしてどんな結果を得たか、目標を達成できたか振り返ります。次は何をしていきたいか議論し、結果と今後の展望を上層部と共有します。
備考
自動化は今までの知見が思いっきり生かせそうなので、個人的にはオブザーバビリティに力を入れたいです。
社内向けにはもっと詳しく書きますが、大体こんな感じで進めていこうとかと！
