この記事は モチベーションクラウドシリーズ Advent Calendar 2022 16 日目の投稿です。
弊社ではテックブログもやっておりますので、宜しければこちらもどうぞ！
https://link-and-motivation.hatenablog.com/
はじめに
アプリエンジニアからSREに配属されて２年が経ちましたが、やっとSREとしてバリューを発揮できるようになってきたので、SRE初心者だった自分が、今でも意識していること・取り組んで良かったことを５つ簡単にまとめました。
1. クラウドサービスを徹底的に理解しろ！
弊社はAWSを使っており、運用全てAWSを使っているので、まずサービスの理解を深める必要がありました。
以下にアーキテクチャの理解・運用の理解に必要な抑えておくべき主要なサービス一覧を示します。
| カテゴリ | サービス一覧 |
|---|---|
| コンピューティング | EC2, Lambda, Elastic Beanstalk |
| コンテナ | ECR, ECS, EKS |
| ストレージ | S3 |
| データベース | RDS, ElastiCache |
| ネットワーク系 | VPC, CloudFront, Route53, API Gateway |
| 開発ツール | CodeBuild, CodePipeline |
| 管理・ガバナンス | CloudWatch, Systems Manager |
| 分析 | Athena, Kinesis, Glue |
他にも必要なサービスはあるかとは思いますが、主にこの辺を押さえておけば大抵の業務に困りませんでした。
2. トイルに誰よりも敏感であれ！
トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加するといった特徴を持つ作業のことを指します。
開発生産性を上げるまず一歩目としてトイルの削減が必要です。
自分はSREとしてSRE内でのトイル、開発組織のトイル2つの観点から課題を抽出し、1つずつ自動化していきました。
トイルを削減した例をいくつか以下に示します。
| トイル項目 | 削減時間（1回の作業あたりの時間) | Before | After |
|---|---|---|---|
| リリース作業での手作業 | 0.5h → 0h | ・手動でtag打ち ・リリースブランチの作成 ・リリースフローが複雑、かつ手動でのリリース ・etc |
・tag打ちの自動化 ・リリースブランチの作成の自動化 ・リリースフローを整理し、自動でリリースできる仕組みを構築 ・etc |
| 本番環境変数の追加 | 1h → 0.1h | ダブルチェックで本当に問題ないかを確認しながら、GUI操作で追加作業 | コード管理することでレビューのみの時間で、リリースされると安全に追加される仕組みを構築 |
| メトリクスの収集 | 1h → 0h | 4-keysのメトリクスに必要な情報を手作業で計算・収集 | GitHub Actions・Looker Studio等を使って自動化 |
結果が出やすく価値のあるものなので、SRE初心者こそ最初に取り組むべきことだなと思いました。
3. 開発者との協働を忘れるな！
SREが勝手に良くしたとしても、開発者にとって本当にそれが良いものかはまた別の問題と捉える必要があります。
なので、運用まわりの変更等の開発者が関わるタスクは、要件定義の段階で開発者を巻き込み、意見をもらいながら、運用に乗るまでしっかりとフォローする必要があります。
SREのアウトプットは、運用が乗るまでがアウトプットである！
と自分は認識し、日々のタスクに取り組んでおります。
4. 監視の通知を見逃すな！
弊社はサービスの監視をDatadogを使ってSlackのチェンネルへ通知をしています。
「これはどのような現象か」を通知が来たときに、素早く察知し、対応するためになんの監視をしているのかを把握する必要があります。
よくあるのはオオカミ少年アラートです。
通知は来るが問題がないため無視してもいいアラートのことを言いますが、これを０にし、対応する必要があるもののみに整理することが重要です。
放置しておくと、重要なアラートが埋もれて気づかなかったり、見ても意味がないと認識してしまうと監視しているチャンネルの重要性が薄れてしまうからです。
また、画像のように通知に気づきやすくするため、Slackのメンション機能を使うことで、漏れを無くします。
5. ダッシュボードで見える化しろ！
これは最近取り組み、重要だと思ったことです。
弊社はDORAが開発組織のパフォーマンス指標で掲げている4-keysを導入し、開発メトリクスを測定しております。
直近まではメトリクスをスプレッドシートで集計し、グラフ化や結果をまとめていましたが、開発者にとって非常にわかりにくく、SREのみ理解している状態でした。
この問題をLooker Studioを用いて、ダッシュボード化することで開発者が現状を把握でき、また、どこに問題かありそうかの分析にも使えるようになりました。（分析に関しては今後の予定です）
このように監視すべきもの、分析すべきものはなるべくダッシュボードで見える化する事で取り組むべき新たな課題の発見や活発な議論を促すことができます。
簡単にできることなので、もっと早く取り組めばよかったと思ってます。
さいごに
もちろん、SREの業務は多岐に渡るので、他にもたくさん重要なことはありますが、自分がやったことと意識したことベースで書かせていただきました。
全てこれに集約できるものではありませんが、SRE初心者にとって最初に取り組むと結果がすぐ出やすいものではないかなと考えております。
何かの役に立てれば幸いです。