「SREに興味はあるが、どのように取り組めばよいかわからない」という企業も多いでしょう。
また、「SREチーム」を形だけ作って進めてみたものの、みるみるうちにチームメンバーが疲弊していき、SREの効果も全く見えずに失敗した、といった企業も多くあるかと思います。
本記事では、疲弊しないSREチームを作るために必要な6つのポイントを紹介します。SREチームをどのように形成すればよいか悩んでいる企業様は参考にしてみてください。
SREチームの重要性について
まずはSREを導入する重要性について再確認しておきましょう。
SREとは、Googleが提唱した信頼性向上のための施策のことです。「SRE サイトリライアビリティエンジニアリング」によると、「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」と解説されています。
一般的に、サービスが拡大しトラフィックが増加すると共に運用チームの負荷は大きくなります。運用上のトラブルは新機能を追加する際に起こりがちで、安定的に運用したい運用チームと、新機能をどんどん追加したい開発チームでしばしば対立が起きてしまいます。そのような課題を解決するためにSREが必要とされています。
SREでは、手作業で行なっていた作業をエンジニアリングで自動化し、運用の負荷を減らします。運用チームの負担を減らすことで、ユーザーに求められる新機能や改善のためのリリース頻度を高められるでしょう。また、従来の手法ではサービスが拡大するにつれて運用チームの人数を増やしていく必要があったのに対し、SREを導入すれば運用チームの規模拡大を抑えられます。
自動化によってヒューマンエラーを減らせるのもSRE導入のメリットです。
昨今のシステムでは可能な限りダウンタイムを減らすことが必要不可欠です。ヒューマンエラーを削減できれば、トラブルによるダウンタイムも減らせる可能性があります。
Googleでは、次のような構成のSREチームを作っています。
- Googleに正式に採用されたエンジニアが50〜60%
- Googleのソフトウェアエンジニアリングの必要条件をほぼ満たし、SREに有益なスキルの中で、他のエンジニアが持っていないスキルを持ったエンジニアが40〜50%
すべてのSREに対して、トイルと呼ばれる運用業務の合計を50%以内とするよう求めています。トイルとは、例えば次のような業務を指します。
- チケット
- オンコール
- 手作業
トイルにかける時間を削減することで、残りを生産性の高い活動にあてられます。これが、Googleが提唱しているSREのルールです。
疲弊しないSREチームを作るための6つのポイント
SREチームを作ってみたものの、チームメンバーが疲弊してしまい、うまくいかなくなってしまうことがあります。疲弊しないSREチームを作るためには、次の6つのポイントに注意しましょう。
- 自社にあったSREを導入する
- 導入に不可欠なステークホルダーの協力を仰ぐ
- オンコールとアラートの適切な管理を行う
- ポストモーテムの文化を根付かせる
- まずは小さく始める
- SREのあるべき姿を模索し変化し続ける
ここでは、それぞれの項目について詳しく解説します。
Googleの提唱内容はあくまで参考にし、自社にあったSREを導入する
GoogleはSREに関してさまざまな提唱を行なっていますが、その内容はあくまでもGoogleに最適化されたSREのスタイルです。
企業の規模やメンバーが持っているスキル、業務内容などは企業によって異なります。そのためGoogleの提唱内容を全て受け入れると、どうしても自社にあわない部分が生じます。
しかし、SREはGoogleのように特別な企業のためだけのものではありません。事業規模や事業の成長フェーズや社員のスキルなどを考慮し、SREの要素の中から必要な部分のみ取り入れていくことが現実的です。
導入に不可欠なステークホルダーの協力を仰ぐ
SREのスムーズな導入には、SREチーム以外のステークホルダーの協力が欠かせません。例えばプロダクトマネージャーや各開発チームのリーダーなどが挙げられます。
ステークホルダーには、なぜ今SREチームを設置するのか、SREの業務範囲をどこまでに設定するか、定期的な情報共有をどのように行うかなど、予め決めておく必要があります。
特に、事前にSREの業務範囲をどこまでにするか決めておかないと、運用のほとんどをSREが管理する状況に陥り、疲弊に繋がるため注意が必要です。
新しいことを始めるときにはさまざまな衝突が起きやすいものですが、ステークホルダーの協力があればスムーズにSRE導入を進められます。
オンコールとアラートの適切な管理を行う
よくあるケースとして、大量のオンコールやアラートの対応により、SREチームが疲弊してしまうという事が挙げられます。
サービスを運営していくうえで、オンコールやアラートの管理は必要不可欠です。しかし、大量のオンコールやアラートの発生は、担当者の感覚を鈍らせ、対応の見逃しや無視、遅れといった問題を引き起こす原因となり得ます。
そのため、「そもそも不要なオンコールやアラートの対応が発生しないように、運用やシステムを見直し続ける」という視点を持って改善に取り組むことが非常に大切です。
また、各メンバーのトイルとその他の作業の割合を適切に計測できる環境を構築し、トイルの割合が平準化されるような運用体制を整えておくことも重要です。
ポストモーテムの文化を根付かせる
社内にポストモーテムの文化を根付かせることも重要なポイントです。
ポストモーテムとは、トラブルや障害が発生した後の検証とそのドキュメント化を指します。発生した問題にその場で対応し解決するだけでなく、根本的な原因の追求によって同様の問題発生を防ぎます。
とはいえ、ポストモーテムには多くの工数がかかります。どのレベルの問題が発生したときにポストモーテムを行うか、インシデントが発生する前に条件を決めておきましょう。
ポストモーテムは、問題を発生させた人に対する非難になってはいけません。事実に基づき、原因と対応、そして今後の改善について建設的に議論や指摘が行われる必要があります。
また、ポストモーテムの文化を組織に定着させるために、ニュースレターの発行やポストモーテムの読書会などを行い、個人やチームの学びを、関連する開発組織全体に広めていくことも必要です。
完璧を求めずまずは小さくはじめること
SREの導入では、最初から完璧を求めてはいけません。まずは小さな規模から始めて、だんだんと規模を大きくしていくのがおすすめです。
SREを初めて導入する際には、なるべく自社のメンバーで始めましょう。なぜなら、SREに関連するスキルを持った人材は少ないため、新たに外部からSRE経験者を採用しようとすると、優秀な人材が見つからない、人材は見つかったが年収が高額になりがちといった傾向があるためです。
組織によってSREのはじめかたも異なります。例えば「はじめから10名以上のメンバーをアサインして、フルタイムのSRE組織を設置する」ようなケースもあれば、「専任のSREは不在で、全員が開発組織内の兼任エンベデッドSRE」といったケースもあるでしょう。
自組織において、どのようにSREを行うかについて、試行錯誤するのは悪いことではありません。ただ、試行錯誤のプロセスにおいて後戻りがしやすい形であるほうが望ましいです。そんなとき、自社のメンバーだけで始めたSREであれば、すぐに路線変更しても「投資した人件費が無駄になった」といった問題は生じません。
社内のメンバーだけでSREを導入するのが難しい場合、新たに社員を雇うのではなく、導入支援サービスを利用することも検討してみてください。
SREのあるべき姿を模索し変化し続ける
SREのあるべき姿を常に模索し、変化し続けることも重要です。
サービスはユーザーの要望や環境によって常に変化します。そうした変化にともなって、SREも変わっていかなければなりません。
自動化によって運用業務を効率化し、効率化によって生じた時間でさらなる自動化を行うのが、SREの理想の姿です。サービスに関してSREチームが得た知識を、助言や提案として開発チームに共有することでも、運用業務の効率化が期待できます。また、既にSREが最適化を行った領域であっても、技術の進化によりさらなる最適化が可能となる場合もあります。
つまりSREは、適切な姿を追求すればするほど業務効率化が可能です。効率化によって社員が生産性の高い仕事に関われる時間が増えるため、モチベーションアップにもつながります。
SREの導入及び運用サポートは弊社3Shakeにお任せください！
疲弊しないSREチームの作り方がわかっても、実際にSREを導入するとなると何から始めたらよいかわからない、と悩んでいる企業様もあるのではないでしょうか。
弊社3Shakeでは、SREの導入および運用のサポートを行なっています。金融や医療、AIなど、さまざまな分野で経験を積んだSREの専門家が、SREを総合的に支援いたします。
SREの導入をお考えの企業様は、ぜひ一度お問い合わせください。
サービス詳細や料金についてのご質問・ご相談などお気軽にお問い合わせください
サービスのメリットや紹介テキスト
金融・医療・動画配信・AI・ゲームなどの様々な領域での実績から、最適な課題設定と解決策を提示します。
SreakeではSREや関連する情報を発信していきます。