好奇心の足跡

飽きっぽくすぐ他のことをしてしまうので、忘れないため・形にして頭に残すための備忘録。

DevOps文化の組織にSRE活動を導入した話

SRE DevOps マネジメント

2018年 SRE Advent Calendar 10日目に寄せて書きました。

qiita.com

もしこれから参加される場合は、2もあります。

qiita.com

今回は、自分たちの部署が2014年頃から築いてきたDevOps体制の中で、どうSREの考え方と活動を導入していったかについて書きます。同じような事情・背景の組織も多いのではないでしょうか。

DevOpsとは？SREとは？についてはたくさん記事が出ていますので、参考リンクを読んで頂ければと思います。

前置きが長くなってしまったので、お急ぎの方は「どういう体制がFitしたか」から読み始めていただくとよいかと思います。

DevOps体制を始めたきっかけ

私が今の部署に異動したのは2013年の秋頃でした。クラウドサービスを開発して運用する部署、ということでハードウェアが主戦力なうちの会社にしては大変珍しい部署で、私も組込みソフトウェアの部署から右も左もわからぬまま異動してきてワクワク・ソワソワしていたのを覚えています。
その頃は、複数のサービスを一つのシステムの上に構築しており、開発チーム複数とインフラチームが一つ存在する、典型的なDevとOpsが分離した体制でした。
組み込み系の組織だとこの体制は当たり前ですし、当時はまだまだ運用・Deploy周りは一定の技術と経験が必要とされていたので自然な流れだったのかもしれません。
しかしこの体制では、下記のような問題が出てきていました。

  • インフラチームが開発の内容・変更点を知りきれないため、Deployや運用時に問題が起きたときに適切に対処できない
  • 開発チームが多くなる/リリースが重なるとインフラチームの負荷が高まり、結果回しきれなくなってリリースが遅れる
  • 上記の問題でインフラチームのリソース調整が行われるようになった結果、修正からリリースまで2週間以上Defaultでかかるようになる
  • 開発チームとインフラチームでの設計・開発時点でのコミュニケーションがほぼないので、運用を意識した設計・開発がされず、運用が始まってから問題が発覚する
  • 結果、開発チームとインフラチームがお互いに不満を抱えたまま対立し始める

どれも「あるある」だと思うんですけど、本当に「あったあった」で、この手の話を聞くと首がもげるほど頷いちゃいます。ちなみにこの時、私は開発チームでした。

こういう背景もあり、また別のゴタゴタもあり、体制を見直そうという動きが出たのが2014年春頃。
流行りのDevOpsという言葉を使いつつインフラチームを解散し、各開発チームにインフラメンバーを送り込むということで、体制がガラリと変わりました。
この時期になると、各クラウドベンダー(主にAWS)からいろんなサービスが出てきて、インフラの仕事や運用監視も開発メンバーが担いやすくなったというのも大きかったと思います。また、新しいことをやっていくにあたって開発速度も上げていきたいし「小さくたくさん」回していきたいという開発・マネジメント陣の思いもあったかもしれません。

そんなこんなで動き出したDevOps、各開発チームの中で設計・開発・運用が閉じるようになり、開発スピードは格段に上がりました。また、チームによるかもしれませんが、私の所属していたチームでは従来のインフラメンバーがコードを書いたりテストの面倒を見たり、逆に開発チームがインフラコードを書いたりトラブルシュートの一次切り分けをしたりと、役割の流動化が進みました。
もちろん得意・不得意はありますし、皆が皆今までと違う役割を受け入れて挑戦したわけではないのですが、開発も運用もいけるメンバーが増えたというのは大きな収穫だったと思います。かく言う私もこの時期にインフラ寄りの作業を設計から実装・運用まで担当し、面白さに目覚めたわけです。

SREを導入したきっかけ

良いことばかりだし、開発速度も上がったならめでたしめでたしじゃないか！
なんですけど、DevOps体制で突っ走ってみると、問題とは言えないまでも課題が見えてきました。

  • 各開発チームが分断されてしまい、同じような機能を作ろうとしているのに設計やCIなどの環境も一から検討し直していて非効率に見える
  • 運用しているサービスのSLA/SLOの監視方法がそれぞれの開発チーム任せで、認識しているかどうか怪しい＆観測方法が揃っていないので他所から聞かれたとき説明しづらい
  • 起きた問題・障害の情報が共有されておらず、同じ問題が発生しそうな設計のシステムが出来上がってたりする
  • 特にインフラ面でハマった問題の共有がチーム間でされず、同じところにハマって悩んでいることがある
  • 新しい技術・サービス(特にインフラ周り)のキャッチアップがチーム間で共有されずにそれぞれのやる気任せになっている

ほとんどの課題が他チームとコミュニケーションしたら解決しそうなんですけど、DevOps体制になってからどうしても各チームがサイロ化してしまい、偶然ランチを一緒に食べていた他チームのメンバーから共有された話で（クラウドベンダーの障害を知るなどして）助かった、的な話もよく聞くことになってしまっていたわけです。
また、チーム間での技術レベルにも差が出てきていました。新しい技術・情報を積極的に取り入れて共有する文化のあるチームでは、新しいサービスを積極的に使ったり、アプリケーションコードだけではなくインフラコードもより良い書き方を追求してブラッシュアップしていく一方、あまりそういった活動が活発でなかったり忙しすぎて目の前のタスクをさばくのに必死なチームでは古い設計・サービスを使い続けていたりCIの導入やインフラのコード化ができていなかったり。
更に、我々の部署では今後もできればあまり人数を増やさず、しかし手がけるサービスは増やしたいということで、特に運用面での効率化・Toilの削減は課題の一つでした。

SREチームの役割としては、GoogleのSRE本にも「厳密な定義はない」とありますが

  • サイトの信頼性を保証する
  • 運用業務とサイトの信頼性向上の2つの役割を担う
  • 積極的にコードを記述
  • 運用をクラウドや自動化に置き換える (Toilの削減)

このあたりがポイントのようです。
※ Googleが提唱した「Site Reliability Engineering（SRE）」とは｜フリエン より

上記の我々の部署の課題を解決する一つとして、組織としての「SLA/SLOとその観測項目・方法」を定義し、監視していくことはSRE活動の目的にも合いそうです。
また「SREやるよ」という動きを通じて、各チームのインフラ・運用とSRE活動に関わりそうな情報全般の共有をできる場が設けられるとすると、これも我々にとってプラスになりそうです。既存の設計やコード・ツールの共有、新しい技術やサービス情報、脆弱性情報の収集・共有、起きた問題やハマりポイントとその対処法、パフォーマンスの分析と改善の取り組みなど、共有したいことは山ほどあります。

どういう体制がFitしたか

Google本でも SREチームの形はそれぞれとありますし、GoogleのSREチームの形を丸々なぞる必要はありません。SREはスーパーエンジニアの集団だという記述もよく目にしますが、"スーパーエンジニア"の集団がそろっている組織なんてそうそうないでしょう。
ということで私達は、今感じている課題をSREの活動とうまく合わせて解決に持っていく、もしくは各々の技術・知識を高める方向に持っていくことに重きを置きました。

メンバーを各チームから集ったり外から募集して「SREチーム」を新しく設立、100% SRE 業務に充てるというのも思い切りが良くて良いやり方だと思います。
一方、私達は下記のことを考慮して、SREチームの体制を検討しました。

  • 急な体制の切り替えで普段の運用や開発が停滞してしまうことを防ぎたい
  • SRE活動に興味のあるメンバーばかりではない（インフラ要因としての役割のみで満足している）
  • そもそもSRE活動、というものがうまく回る保証がない（ので実験的に始めてみたい）

ということで、こんな形になりました。

f:id:kusuwada:20181206120236p:plain
SRE体制

具体的にはチームが10前後ある中で、SREチームのコアとなるメンバーを4名確保しました。コアメンバーも各チームから選出されているのでSRE活動に充てる工数は0.5程度です。
このコアメンバーを中心に下記の活動を回します。

  • SLA/SLOの定義やその観測方法の統一化
  • 情報共有会/議論会の開催・ファシリテーター
  • 各チームのToil削減のための自動化・コード化、共通化
  • 各チームで技術的にネックになっている部分のサポート、新しい技術の導入

その他のSREメンバーは、情報の共有会に参加・発表したりSlackで情報を共有し合ったり、コアチームで作ったツールや他チームから共有されたツールを横展開したりします。

7ヶ月の活動で見えてきたこと

この体制で半年活動した時点で、大きな期間での振り返り会（KPT）を実施しました。
そこで出てきた意見も交えつつ振り返ってみます。※個人的な主観もかなり入っています。

よかったこと・継続したいこと (Keep)

  • なかなかバランスの良い体制だった
    • メンバー全員が各DevOpsチームとしても動いているため、サービス内容や開発側の事情もよくわかってSRE活動がしやすかった
    • SREとしてのみ活動していると、過去の体制のように開発と分離してしまう可能性もあったが、この体制だと大丈夫
  • 毎月一定の成果をあげてこられた
    • リリース・サービスイン・障害対応、など明確な目標が立てづらい活動のため、「アウトプット重視」を最初に掲げてスタート
    • Sprintごとに必ず自分の成果を共有サイトにアップすることを徹底、月次で成果物を簡単に紹介する会を設けた
    • SRE活動としての追加メンバーほぼなし・全員DevOpsと兼務という条件下でも、SRE活動の成果を実感できて良い取り組みだった
  • 情報共有会やSlackによるコミュニケーションによる、サイロ化したDevOpsチームのつながりが持てた
    • 他のチームでやった内容を自分のチームに持ち帰る、共有会で知った新しいサービスを試してみる、などの動きが活発に
    • それぞれのDevOpsチームの中で個別に悩んでいたところをインフラ脳が集まって議論できる場が出来て楽しい

改善したいこと (Problem)

  • Coreメンバーは SRE チームとしての工数が0.5のため、複数プロジェクト掛け持ち経験がないメンバーにとっては時間のやりくりが難しかった
    • こちらは、スケジュールのたて方・計画の仕方など工夫することにより、徐々に改善
  • もともとインフラよりのメンバーから集まっているため、バリバリコードを書くメンバーが少なく、実装を伴う作業がそのメンバーに集中しがち
    • 開発よりメンバーからSRE活動要員を調達する・既存インフラよりメンバーのコーディング力を上げる、など試み中

挑戦したいこと (Try)

  • CoreメンバーとProjectメンバーをローテーションしたい
    • Coreメンバーの活動に参加することで、より技術の向上や情報のキャッチアップが見込める
    • もともと構想にあったが、なかなか業務都合がつかなかったりで実現できていない
  • 自分たちの活動がどのように役立っているかを、何かしらの方法で見える化したい
    • 共通ツール作ったけど役に立ってる？どれくらい？など

おわりに

"SREとは"という定義にはもしかしたら厳密には当てはまらない活動かもしれませんが、私達なりの解釈で自分たちの組織に合う活動をしてみたらこうなりました。
何かしら新しい活動を始めるのに看板は大事です。そこに"SRE"という、キラキラしている企業がこぞって導入しているワードを使い、メンバーのモチベーションを高めるのも一つの方法だと思うのです。なので、SREやってみた話を聞いて「いやそんなのSREじゃねーし」と切り捨てるのではなく「そういう切り口もあったか」「この組織の課題はそこにあったのか」みたいな受け止め方も面白いんじゃないかな、なんて思う師走なのでした。
今後もSRE活動の看板のもと、メンバーの技術力・知識の向上や、失敗事例・成功事例の共有、共通化や効率化に努めていきたいと思います！

参考リンク

素材リンク

今回の図の素材は下記サイトから使わさせていただきました。