SRE 立ち上げからの1年半を振り返る

EMとしてSREの立ち上げをして1年半が過ぎていた。あっという間だった。まとめておこう。いや書き殴っておこうの方が適切かもしれない。

ミッション

方向性としては、DevOps文化を会社に根付かせよう。

プロダクト開発チームが設計・開発・リリース、監視、ロールバックなどのDevとOpsの双方を自律的に取り組めるチーム作りを推進していく。

ターゲットとなるプロダクトは複数ある。それぞれ開発チームがいる。

インフラだけでなく、可観測性基盤（モニタリング、ロギング等）、CI/CDなどのDevOpsに関係する基盤整備やアップデートなどの構築・運用・保守および支援を遂行する。

インフラおよびアーキテクチャ面ではHA、DR、スケーラビリティ性などを達成するために構築・支援していく。

メンバー

私も含めてソフトウェアエンジニアがバックグラウンドの人達で構成。というよりも現職にはインフラ専門のエンジニアがいない。フルスタックなエンジニア達の中からインフラや可観測性基盤構築・運用に興味がある希望者が集まって組織している。

立ち上げ時

立ち上げ時はインセプションデッキを利用してチームのミッションを明確化。役割の明確化したことでインフラ開発系の業務がドドドッと入ってきてパンパン。

その上で割り込み業務が多くて改善が進まない状態に陥る。通常業務も回らなくなる。

KANBANを導入し始める。

割り込みをこなしながらトイル削除に励む

ロードマップを見直す。トイル削除を優先的に遂行。

エンジニアによっては5割以上割り込み減った。体感的には頭のコンテキストスイッチが減ったことで8割くらい減ったように感じるらしい。

エンジニアの負荷になっている技術的負債の返済も積極的に推進する。インフラのコード化が進む。

トイル削除は単純に自動化をするのではなく、問い合わせ業務（ヘルプデスクっぽいお仕事）が発生する原因を突き止めて、ワークフローなどの改善も含めた社内向けのコンサル業務ライクなことを推し進めて、問い合わせをしてくる社員の業務もハッピーになるように進めていった。

改善していくたびにSREへの問い合わせが減っていく。

これって「SRE」の仕事なのか？と疑問を持つようになる。
社内に業務改善コンサルチームがあるような状態に陥っていることに気づく。

プロダクト開発チームのDevOpsが自律的に進化し始める

プロダクト開発チームがポストモーテムを自ら書くようになってきた。

プロダクト開発チーム発案で「障害基準」をつくり、それに基づいて障害対応をする新しい習慣が生まれる。随時アップデートもされている。

アプリケーションエラー通知系のカスタマイズで状況変化をいち早くキャッチできるような改善もプロダクト開発チーム発案で生まれる。

素晴らしい。

ポストモーテムの振り返りによる気づき

SREでは過去に障害があったケースの勉強会として「ポストモーテムのふりかえり」を定期的に実施し始める。

事情はあるようだが、その場限りの修正で完了になっていることが多いことに気づく。根本的な原因解決になっていない。同じ不具合が再発する。複数プロダクト開発チームで類似したことが繰り返し発生する。何か問題がある。業務コンサルライクなトイル削除が役に立った。

SLI/SLO/SLAは困難を極める。

SLAはいったん見送りという判断になる。

可観測性基盤が徐々に仕上がってくる。ようやく現状が見えるようになってきたことで、SLI/SLOの策定ができるようになってくる。パイロット運用も始まる。しかし、いざ合意をとろうと交渉段階に入っていくと例外が多過ぎてシンプルに運用できない。

メトリクスも・・・多い・・・な。

みんなどうやってんの？

そもそもSLO、SLIってなんのためにあるのか考え直す。さまざまな可観測性系SaaSを調べていくうちにあるIndexに出会う。なるほど、そういうことか！！

エンジニア視点ではなく、ビジネス・ユーザー目線でサービスに求められることを表現できるINDEXを利用すればいいのだ。完璧さよりもわかりやすさが大切だ。

SRE本や周辺の成功事例を持ってきて導入しようとしていた。とても恥ずかしい。アジャイル（スクラム）において他社事例を持ってきて、導入してもうまくいかないことと同じだった。

経験している内容を他分野で活かせなかった、気づくのに時間がかかったのは反省。

ScalabilityとReliabilityは別？

ある会社のお話をお聞きする機会があった際にScalabilityを担保するチームとReliabilityを担保するチームが別れていた。それぞれ責務を持って活動している。もちろん協力し合う関係だ。

なぜ分けるのか非常に興味を持ったが、ご質問できなかった。

たとえば、スパイクによる瞬断が起きてしまった際にそれでもSLAを満たしていたらどうするのか。という疑問が起きる。

ビジネス視点・ユーザー視点で考えるなら対応すべきだ。

分けて考えた方が良い。

メンバーの評価

SREは業務によって売り上げなどのビジネス面のKPIに向上する役割ではない。そのため、素晴らしい成果を出せてもメンバーの評価を私の期待通りにあげられず苦心した。チーム内での評価をUPさせても全体の調整によって、かき消されてしまう。

SREは関節部門のような扱いになっている。プロダクト開発チームとそのビジネス部門は花形のような立ち位置であり、SREは黒子のような役割だ。

光が当たらない。

「成果がわかりにくい」と上司に指摘される。

対策として、メンバーにはトイル削除をはじめとした改善のレポートを毎回作るように強く推奨した。チーム内でレビューを通した効果分析の精度アップ。成果を定量化したり、本人が気づいていない副次的な効果も含めて、様々な効果があったことを事実として記録していく。定性的な内容も含めてだ。ひとりひとりの成果をチームで支えて、アップデートしていく。話し合いを繰り返すことで私自身気づいていなかったアイディアに辿り着く。

On for All , All for One .

その成果として「あのチームの成果が上がっているのはSREが改善したから」ということが成果につながるようになった。レポートがありEMとして評価されるに値する成果である水準に引き上げていく。

今思えば、360度評価のように関連部署の方にフィードバックをいただける制度があればここまで苦労しなかったのかもしれないと思う。

半期毎に評価があるため、3回のイテレーションを回すことができた。

全体最適化

複数のプロダクトを横断的に見ているため、なるべく複数のプロダクトに展開できないかを先に考えてみる。コストや今後の戦略等の経営視点も含めて全体最適化を図れないか意識的に取り組むよう推進。

リリース優先すると部分最適化が進んでしまうリスクが発生する。

うまくいくと作業量はあまり変わらないが成果が数倍になる上にプロダクト間で共通基盤化が進む。成果は数倍どころではない。

ただし、リードタイムも重要なのでバランスが難しい。

透明性向上とチームビルディング的効果

チーム内で互いの成果をレポートしてレビューするようになってからだ。チーム内でそれぞれが何を取り組んでいて、どんな結果になったのかがメンバー同士で明確に分かるようになった。

レポートに対する事後の質問も発生し後に他プロダクトへ横展開されることになったものもある。

チームメンバー同士で評価についてのフィードバックをお願いしたところ、「すらすら書けた」という感想をいただいた。

採用活動

SREとして初めての採用活用を行った。JD作成の経験をした。採用プロセスの設計もした。メンバーと話し合い、Site Reliability Engineerとしての像をみんなで話し合ってJDに落とし込めたことは良い経験になった。

数ヶ月間トライアルで行ったが、残念ながら良い結果に結びつくことはなく打ち切りとなった。

SRE経験者は非常に希少らしく争奪戦らしい。潜在的な応募者が魅力的だと思っていただけるブランディングをしないと優秀なエンジニアは現職を選んでくれないと痛感した。

私もSREとして現職に応募するかな？と思った時に疑問に思った・・・・たぶん、そういうことだ。

資格取得

SREになってから何を勉強すればいいのかチームで話題になりメンバーからAWS認定資格を取得したいという声があった。

会社では資格試験受験の全額補助が出る（合格時のみ）。学習用の書籍購入の全額支援制度はすでにあったが、いざ勉強しようとすると書籍が充実していないことに気づく。むしろ別の勉強方法が良い。私も体験して気づいた。

オンライン学習サイトでの利用制度を提案し制度化。勉強しやすい環境を構築した。

私自身、AWS認定資格を率先して取得して4つ取得。メンバー全員がAWS認定資格ソリューション・アーキテクト・アソシエイトを取得している。どうやら他の資格もとりにいくらしい。

サーバントリーダーシップ

1年半が経過してきてエンジニアが成果を最大化するためにサーバントリーダーシップに徹するようになってきた。

よりサポートできる体制になってきたことが大きい。

私自身がハンズオンをしなくてもチームとしての成果を出していける状態になってきた。おそらく次のフェーズに入ったのだろう。

自ら課題発見してくれるようになり提案してくれる。頼もしい。

所感

この1年半で得られたことはとても大きかった。SREの立ち上げから始まり、少しずつチームを機能させていくことを経験した。

新規事業でもチーム立ち上げは経験したが、何度経験しても難しいと思う。同じことを繰り返しても成功しない。再現性を高めるにはより高次元のスキルが必要だ。SREと新規事業の2種類を経験したことでチームビルディングのスキルは高まったように思う。

今回は業務内容の定義からスタートした。業務内容は進めていく中で徐々に変化していった。ひとつのプロダクト開発チーム内にずっといたら得られなかった経験をできたと思う。

複数のプロダクトチームに横断的に関われることで、視野が格段に広がった。常にふたつのチームの差分を見続けられる環境にいたおかげだ。

こっちのチームがうまくいってるのにあっちのチームは難しいんだろうと考えるようになった。

その課題を分析していく過程で組織マネジメントに興味を持ち始めた。

非常に感謝・感謝。

システム思考、氷山モデルを理解していく中で目の前でおこっている出来事だけに囚われずに時系列パターンや構造にも注目していけるようになってきた。そして個人やチーム、組織のメンタルモデルについても気にかけるようになってきた。

世界の見え方が変わってきていることは明らかだ。

これから

まだまだお仕事はたくさん残っているが、自分の中ではひと段落した感が強い。

重要なワークが残っている。

おそらくそれを完遂したら、私がこのチームを去っても彼らは成果を出し続けられるだろうと確信している。

立ち上げ時からずっと考えていた出口戦略。

以上。