「名ばかり」SREと「できる」SREはどこが違う？
サイト安定稼働のためのSRE（Site Reliability Engineering）チームの役割はサービスのモニタリング、効率、変更管理、緊急時の対応、キャパシティプランニングがある。求められるスキルには、スクリプティング、クラウド管理、運用監視、CI/CD、ネットワーク管理、データベース管理、ミドルウェア管理がある。SREがレベルアップするための方策について、シスコシステムズ 関屋信彦氏が指南する。
スキルや経験が足りない「名ばかり」SREはサイトの監視をしていつつも、一般的なインフラ監視項目以外は開発チームに一任してしまいがちだ。SREもDevも互いに丸投げしてしまい、本番運用後にコネクションプールやAPI単位のトランザクション性能などが問題になってしまう。例えばユーザーからエラーが報告されても、下記のようなやりとりで的確な調査ができず、問題解決できずに終わってしまう。
ユーザー「画面が真っ白で何も表示されません」
名ばかりSRE「500エラーが発生している。開発者に聞こう」
開発者「白い画面だけじゃ分からない。エラー前後の動作は？ 再現性は？」
ユーザー「また画面が真っ白です」
名ばかりSRE「再現したらしいです」
開発者「アプリのバージョンは？ コードをチェックアウトして確認しないと分からない。今は立て込んでいるから数日待って」
開発者がアプリに問題があるとうすうす感じていても、一部のユーザーだけに生じたエラーだとサービス全体の問題とされずに放置されてしまいがちだ。運用チームに危機感がなくて放置されているうちに、ユーザーに悪い口コミが広がってしまうと、気づかぬうちに売上に悪影響を及ぼすこともある。逆にトラブルシューティングのためにユーザーを長時間拘束すると、ユーザーにも迷惑がかかる。SREが未熟だと、ただ時間を浪費してしまうことにもなりかねない。
熟練の「できる」SREなら、監視項目設定を主導し、開発者からインフラや監視について教えるほど頼れる存在になる。監視項目はリソースのボトルネックを確認できるように準備しておく。単なるインフラ監視にとどまらず、遅延しているAPIが何か、原因が何か、開発にフィードバックできるようにする。加えて不要なアラートは出さないようにする。やりとりは次のようになる。
ユーザー「画面が真っ白で何も表示されません」
できるSRE「500エラーが発生している。アプリケーションログから操作履歴の確認、問題発生時のトレースをして、と。問題のリクエストの詳細はこちらです」
開発者「ここまで問題の切り分けができていると、明日にでも改修可能です！」
さらに準備がいいSREだと、エラーではなく遅延したAPIを検知して、開発者側に改善のヒントをうながすこともできる。もっとできるSREだとビジネス影響も分析して、ビジネス部門に情報をシェアすることもできる。例えば以下のようなやりとりになる。
できるSRE「通常より遅いトランザクションがあります。この影響は2500人におよび、機会損失金額はおよそ2000万円。エラー発生前と比べてコンバージョンレートが15％低下しています」
ビジネス部門「ビジネス影響の規模が数字で分かるなんて！」
開発者「ユーザーにそれほど影響を与えていたなんて。再発防止すべく修正しよう」
これからのSREはAPMやEUMを使いこなそう
未熟なSREだと従来方式で監視や統計化することはできても、アプリケーション視点に踏み込めないなど何か課題を抱えている。できるSREはAPM（アプリケーション パフォーマンス モニタリング）を活用してリクエスト単位でアプリケーションの挙動を調べ、EUM（エンドユーザー モニタリング）でユーザーのアクセス状況を調査することもできる。やっていることがモニタリングからオブザーバビリティへと進化しているのだ。
APMで可視化するべきポイントは、トランザクションの実行状況、SQLの実行状況、他サービスを呼び出すならプログラムコードの性能、外部サービスの呼び出し状況だ。
アプリケーション監視では全てのエラーを検知するだけではなく、次のような項目を把握できるようにしたほうがいい。遅いSQLの原因は何か（CPU不足か実行計画か）、リクエストを処理したサーバーやコンテナはどこか、GCがどれだけ発生していたかなど。またトレースデータの保存対象や保存期間を検討しておくといいだろう。
EUMで可視化するべきポイントはアプリ内部の動作やWebページ描画時の動作における、HTMLページアクセス、APIアクセス、リソースアクセス、外部サービスおよび外部リソースへのアクセスとなる。
エンドユーザー監視では、モバイルアプリならユーザーがアクセスしていた画面、クラッシュが発生した画面、クラッシュ発生前の操作、サーバーからのエラー、WebサイトならJavaScriptのエラーメッセージなどを把握できるようにしたほうがいい。また提供される情報がユーザー単位の操作履歴なのか全ユーザーの統計情報かを確認しておこう。
応用編となるが、ビジネスデータを収集するなら、アクセスしているユーザー属性、ECサイトなら商品IDや価格、アプリケーションのバージョン、リクエストごとのレスポンスなどを把握できるといい。
