日本国内でも、サービスの信頼性向上のためにSREに取り組む企業も増えてきました。しかし誤ったやり方で実施したがゆえに、思ったように成果が出ないと嘆く企業もあるのではないでしょうか。
そこで今回はSREのアンチパターンをもとに、どのようにSREに取り組むのが良いのか考えていきます。SRE導入を検討している企業様は、ぜひ最後までお付き合いください。
SREにおける代表的なアンチパターン
ここでは、SREを実施するうえで起こりがちなアンチパターンをいくつか紹介していきます。自社でSREを導入する際に同じ状況にならないよう、参考にしてみてください。
看板を建て替えただけのSREの結成
SREは表面だけ見れば、エンジニア集団とインフラ集団、運用集団をひとつにまとめ上げた集団であると言えるでしょう。しかし、それだけでSREを実施しているという事には当然なりません。SREは必要とされる人間の仲介を減らし、障害の発生頻度を抑えるためにシステムを構築し、信頼性の高いサービス運用を目指す組織ないし取り組みでなくてはなりません。
企業の方針として「SREを導入している」という事実だけにこだわるよりも、SREの基本を理解し、自社にあった取り組みを行うほうが良いのは当然のことでしょう。勢いで始めたSREのせいで「エンジニアが運用まで見るようになり、単純に負荷が増えた」「エンジニア本来の仕事に取り組む時間が無くなった」「何かに付けてSREのせいにされる」といった課題が出ないよう、組織構成含めSREのあり方について議論する必要があるでしょう。
SREがスピードバンプになっている
SREの導入が、サービスのリリースやシステムの変更速度を遅らせるスピードバンプになってはいけません。SREはサービスの信頼性を高めるための取り組みであり、迅速で安定した稼働を実現するためのものであると言えます。
「SRE=安全に取り組む」と捉えてしまうと、慎重さを過剰に重視し、サービスの成長に歯止めをかけ、悪い方向に作用させてしまう可能性もあります。SREが成長を妨げる要因とならぬよう、リリースの優先順位やリソースの配分をうまくコントロールするために、適切なエラーバジェットを設定することも必要です。
SRE=火消し役になっている
SREは、開発から運用まで全てを管理するチームであるため、社内的に「なんでも屋」や「火消し役」のような立場になってしまうことが多々あります。開発面でも運用面でもSREに任せておけば良い、何か問題があったらSREに依頼すれば良い、といった状態にならぬよう注意が必要です。
関係者全員にアラートが飛ぶ
サービスが実運用に入ったら障害発生時には状況に応じてマネージャーや担当エンジニアにアラートを発報して対応を促す必要があります。しかし関係者全員にアラートが行き、全員が集合してしまうという事態も避けるべきです。多くのメンバーが招集されることで
- 意思決定や判断が遅くなる
- 他のオンコールに対して手薄になる
- 担当者の決定がされず「誰かやってくれる」という他責が発生する
といったことが起こりうるため、限られたメンバーにだけ通知することも大切です。 PagerDutyなどのツールではエスカレーション機能を使うことで、段階的な通知も可能なため、上手く活用していくと良いでしょう。
関連記事：インシデント管理ツール「PagerDuty」とはなにか [特徴・機能・メリット]
SLI,SLO,SLAの設定ミス
SREを導入する際に、SLI、SLO、SLAの設定をすることも多いかと思います。SREにおけるSLOの失敗例として以下の例がよく取り上げられます。
「ITサービスの運用において、信頼性の目標を100%に限りなく近く設定してしまう」
そもそも前提として、障害が絶対に起きないシステムを構築することはできません。また、信頼性99.99%を99.999%にするためには膨大な工数がかかりますが、ユーザー体験としてはその 0.009% は微々たるもの（＝ほぼ違いを感じることがないもの）です。つまり、サービス運用において適切な可用性の設定を誤ると、結果に見合わない無駄な工数が増えてしまうという事になります。
計測可能なSLI（Service Level indicator）の設定、適切なSLO（Service Level Objective）の設定、ユーザーが納得できるSLA（Service Level Agreement）の設定をしっかり行う必要があります。しかしこれらの設定を適切に行うのは非常に難しいため、SREの知識がある人を採用する、もしくはSREの導入支援の会社に依頼すると良いでしょう。
ポストモーテム文化の欠落
SREを運用していくうえで重要な要素として、ポストモーテムが存在します。ポストモーテムは、起こってしまったインシデントをもとに、そこに至った原因や問題を追求し、再発させないための取り組みです。ポストモーテムが大切であるという事が分かっていたとしても以下のような点で、取り組むのが難しいと感じることも多いでしょう。
- 機械的な問題なのか人に依存する問題なのか追求しづらい
- 解決した問題に向き合う時間が無駄だと考えてしまう、目先の課題を優先してしまう
- 作成したポストモーテムの振り返りを行わず、なんとなく曖昧に作ってしまう
- 必要な情報や状況説明の記載がなく、実用的なポストモーテムが作成されていない
- 情報が展開されず、再発防止策としての意味をなしていない
- ポストモーテムが人を非難するためのものになってしまう
上記であげたように、ポストモーテムの文化を根付かせるのはとても難しく、メンバー全員で意識できていなければうまくいきません。ポストモーテムはすぐに効果が出るものではなく、中長期的に根付かせることで役立つという事を前提に根気強く進めていくことが必要です。
改善フェーズの欠落
SREは一度目標を定めたらそれでOKということはありません。常にその状況（サービスの成長フェーズや外的要因含む）に合わせた目標を設定しなおし、改善していく必要があります。
「施策の結果を振り返り、改善する」というフェーズが欠落しないよう、振り返るタイミングや細かい単位での評価基準を設けることが必要になります。
Googleが提唱するSREを理解する
前項でSREのアンチパターンを見てきましたが、ここではGoogleが提唱するSREを見ていきましょう。SREの基本を知ることで、導入時の失敗を防ぐことができるはずです。
エンジニアリングへの継続的な注力
Googleは、SREが運用作業（チケット、オンコール対応、手作業など）にかける時間は全体の50%に制限すること、残りの50%はコーディングスキルを用いるプロジェクトの作業にかけることを目標に掲げています。
SREが運用作業に注力している場合、8～12時間のオンコールシフトの間に受け取るイベントは平均して最大で2つであり、「イベントを素早く正確に処理する」「クリーンアップと通常のサービスへのリストアを行う」「ポストモーテムへの取り組む」といった作業にかける時間は十分にあると述べています。
運用作業を50%に抑えることで、開発にかける時間と精度は担保する、というのがGoogleが提唱するSREのあるべき姿なのです。サービスの成長とともに、保守運用工数が比例して増大することないよう、積極的な自動化・省力化が重要になります。
SLIを計測しSLOを設定する
ユーザーが満足すれば、SLOの目標は達成されると前置きしたうえで「100%の信頼性を求めること」は基本的には如何なる場合にも間違っていると述べています。つまり、100%を目標にするのは非現実的な目標であるため、各サービスごとに適切な可用性を設定する必要があるということです。
SLIの一般的な指標は以下の通りです。
- リクエストのレイテンシ（リクエストに対するレスポンスを返すまでにかかった時間）
- エラー率（受信したリクエストを正常に処理できなかった比率）
- 可用性（サービスが利用できる時間の比率）
上記のSLIを計測し、SLOを設定します。Googleの提示するSLOの典型的な例としては
- 50%のHTTPリクエストが300ms以内に返答される
- 1ヶ月間99.9%の稼働率(1ヶ月のダウンタイムが43分)
- 1ヶ月間のHTTPリクエストの99.99%が200OKで成功する
といった目標値が挙げられています。設定したSLOのしきい値に近づく前に、エラーバジェットを執行して対応に取り掛かるということになります。もちろんこれらの目標値や計測内容はあくまでGoogleのものであり、企業の規模やサービスによって柔軟に変更すべき内容になります。
運用の改善
SREが行う運用の改善は、詳細かつ広範囲なアプローチを含みます。ここでは代表的な項目を以下に示します。
(1)モニタリングの改善
人間の解釈に依存する属人的な対応を避けるため、機械的にアラート、チケット、ロギングという3つの指標を使いモニタリングを実施します。
(2)緊急対応時の手順書作成
緊急対応が発生した場合、「即興で対応する」のではなく、「あらかじめ作成された手順書通りに対応する」場合、平均修復時間に3倍の改善が見られるとGoogleは述べています。
(3)変更管理
およそ70%のサービス障害は、稼働中のシステム変更が原因であるというデータをもとに、「漸進的なロールアウトの実装」「高速かつ正確な問題の検出」「問題が生じた際の安全なロールバック」の3つの取り組みを行うことで、リリース速度とリリースの安定性の両立が可能になります。
(4)需要予測/キャパシティプランニング/プロビジョニング/効率的なリソース活用
サービスの成長を予測し、それに見合うキャパシティを担保することが必要です。また、リソースの活用状況をロングスパンで監視しインスタンスタイプやプロセスの配置を見直します。
(5)ポストモーテム
「障害や失敗から学びを得るための定型化されたプロセスを設ける」ことがサービスを運用するうえで必要であるという考えです。問題になったと考えられるアクションを特定し、ドキュメント化して共有することが重要です。
SREの導入から運用支援は弊社スリーシェイクにお任せください！
本記事では、SREで起こりがちなアンチパターンとGoogleが提唱するSREについて解説してきました。しかしSREには「これが正解」という明確なものはないため、「ユーザエクスペリエンスの継続的な改善を重視すること」を念頭において取り組む必要があります。これは事業規模やサービスの価格、使用するユーザーや提供形態によっても大きく異なるでしょう。
SREの導入はまずは小さくはじめて、成功体験を積み重ねていくことが重要です。ただし今回紹介したように、アンチパターンは数えきれないほど存在するため、初めからスムーズに進めることは難しいでしょう。
もし貴社で、自社サービスの運用においてSREを活用したい、SRE組織を立ち上げたい、ベストプラクティスから学びたいという要望がありましたら、SREのプロフェッショナルが集まる当社のSRE導入支援サービス「Sreake」をご活用ください。
SREの組織形成や教育は勿論のこと、貴社の業務内容を理解したうえ、サービスの戦略策定から設計・構築・運用、SaaS提供までSREに必要な要素を統合的に提供可能です。
少しでもSREに興味があるという企業様がいらっしゃいましたら、気軽にお問い合わせください。
サービス詳細や料金についてのご質問・ご相談などお気軽にお問い合わせください
サービスのメリットや紹介テキスト
金融・医療・動画配信・AI・ゲームなどの様々な領域での実績から、最適な課題設定と解決策を提示します。
SreakeではSREや関連する情報を発信していきます。