⛳

Notes from Production Engineering in SRECon15の意訳

に公開
SRE
アドベントカレンダー
idea

Qiita Advent Calendar 2025の海外SRE関連セッション意訳の4日目です。ひとりアドベントカレンダーですが、完走できるように頑張ります。

前回は、Config files vs. flags: story of pain in SREday London 2024の意訳でした。設定ファイルとコマンドライン引数のどちらを使うべきか、という内容です。かなり具体的な内容なので、いろいろな意見があるかもしれませんね。

このアドベントカレンダーでは、海外のSRE関連のセッションを翻訳しながら、私の意見や疑問や補足を追加したものです。私の誤解から誤った説明になっている箇所は、コメントでご指摘お願いします。

このアドベントカレンダーでは、私の意見やコメントは可能な限り、下記の記法で要約と区別します。ただ、そこまで厳密にできないため、要約文中に私の思想が混じってしまうことはご容赦ください。(気がついたらご指摘ください)

紹介するセッションについて

今回はSRECon15から、Notes from Production Engineeringというセッションです。

https://www.youtube.com/watch?v=ugkkza3vKbc

セッション詳細: Notes from Production Engineering | USENIX

Facebook(現Meta)のProduction Engineeringチームの立ち上げに至るまでの5年半の物語を、2009年当時の辛い状態からの変化として語ってくれています。

要約

前提: 私は必要ならドアも蹴破る

私がキャリアの早い時期に学んだのは、問題を解決するためには必要なことをやり、必要な人間になるしかないということだ。

ISPで働いていた頃、鍵のかかったサーバールームの中のサーバを今すぐ復旧しなければならない状況になった。リモートアクセスはできず、鍵も見つからない。鍵屋に電話したり、いろいろな方法を考えたが、時間ばかり過ぎていく。

ある瞬間、私はふと気づいた。このドア、木製だ。
私はドアを蹴破って中に入り、サーバを復旧させた。

その日2つのことを学んだ。

  1. 訓練を受けていない人間がドアを蹴破るのは本当に大変だということ。
  2. それでも必要ならやるしかないということだ。私は問題を解決する必要があった。

この「問題を解決するためなら肩書きや役割に関係なく動く」という姿勢が、以降の話の前提になっている。

肩書きが作る壁と、2009年頃のFacebook

私はソフトウェアエンジニアリングもネットワークエンジニアリングも経験してきた。

  • コードを書いているとき、私はSoftwareEngineerだ
  • TCP/IPのフローをトラブルシュートしているとき、私はNetworkEngineerだ

私は自分の肩書きより、自分が実際に何をしているかで自分を定義したいと思っている。

しかし多くの人は、肩書きのほうに自分を合わせようとする。特にFacebookのような大きな会社では、その傾向が強い。
Dev,QA,Opsと役割を分け、それぞれが自分の箱の中で仕事をする。

2009年頃のFacebookはまさにそうだった。

  • Devがコードを書き、QAに渡す
  • QAがテストし、Opsに渡す
  • Opsがデプロイし、壊れたら直す
  • Dev,QA,Opsが話すのは、何か壊れたときだけ

多くのOpsは新しいバージョンをデプロイしたがらなかった。何が起こるか分からないからだ。
さらに悪いことに、オフィスには物理的な壁もあり、DevとOpsの席は離れていた。彼らに話をしに行くためには、文字通り壁を越えて歩いていく必要があった。

私はこのDevとQAとOpsの壁が前から好きではなかったし、その構造が多くの問題を生んでいると感じていた。

DEVとOPSの座席

Bootcampから締め出されたOpsとしての私

FacebookにはBootcampというオンボーディングプログラムがある。新しいエンジニアは4〜8週間のBootcampで、Facebookの開発とリリースの流儀を学ぶ。

入社して2週間ほど経った頃、私は上司に聞いた。

「いつBootcampに参加すればいいですか?」

上司は困惑していた。そしてBootcampディレクターと話したとき、彼はこう言った。

「なぜあなたはコードを理解する必要があるのですか?BootcampはDev向けです。あなたはOpsです。問題が起これば、そこに書かれているコマンドをキーボードで打てば、魔法のように直るのです。」

私は本当に悲しくなった。

名前だけのSREからのスタート

2009年当時、FacebookにはSREと呼ばれるチームも存在していた。しかしGoogleSREの定義に照らし合わせると、ほとんど何も満たしていなかった。

vsSRE@Google

  • ユーザー数は6ヶ月で3倍に増えていた
  • しかし組織構造もプロセスも、そのスケールに追いついていなかった

SREチームは、ひたすら火消しとオンコールに追われる「なんでも屋」のOpsになっていた。私はここを変えなければならないと思った。

この5年半で私がやってきたことは、組織と役割を作り直し、認識を変えることだった。
そして5つの変化で組織を作り変えた。

  1. Re-org:SREをSROとAppOpsに分割する

まず、機能していないSREチームを分割するところから始めた。改善をするためのエンジニアリソースを捻出するためだ。

  • SRO(SiteReliabilityOperations)
    • 緊急対応
    • サイトを24x7動かし続ける
    • スケーリング対応
  • AppOps
    • ソフトウェアエンジニアリング部隊
    • 様々なツールなどを作っていく(後述)
  1. Hiring:ソフトウェアエンジニアとして採用する

次に私は採用を変えた。

  • SROやAppOpsの採用時の面接内容は構造化されていなかったが、ソフトウェアエンジニアリングと同じような内容にした
  • コーディングと設計の面接し、「詳しい人にエスカレーションするだけの人」ではなく、「自分で問題を理解し、ソフトウェアで解決する人」を採った

私は「ノック型のチーム」にはしたくなかった。ただベルを鳴らして誰かを呼ぶのではなく、自分たちで問題を掴み、解決するチームにしたかった。

  1. オンコールをソフトウェアエンジニアの責務にする

私が行った中で、最も大きく、最も重要な変化がこれだ。

  • それまでSROやOpsが持っていたオンコールを、ソフトウェアエンジニアの責任にした
  • すべてのサービスを一気にではなく、コアなサービスを絞り、そこから移行した

この提案をソフトウェアエンジニアリングチームのリーダーにしたとき、多くのリーダーは私のことを頭がおかしいと思った。しかし私は、これをやらなければ構造的な問題は解決しないと信じていた。

オンコールを経験したエンジニアは、本番で何が起きているのかを深く理解し、より優れたエンジニアになった。
どんな変更がどんな影響を与えるのか、身をもって知ることができたからだ。

  1. BetterPostMortems:SEVレビュー

何か大きな問題が起きたとき、私たちはSEVレビューと呼ばれるポストモーテムを行っている。

  1. EmbeddedOps

AppOpsのメンバーは次第に、ソフトウェアエンジニアリングチームの中に埋め込まれるようになった。

  • 彼らはプロダクトチームのミーティングに参加し
  • オフサイトにも同行し
  • アーキテクチャの議論にも参加する

彼らは「あとから渡されるOps」ではなく、「最初から一緒に作るパートナー」になっていった。

しかしAppOpsという名前は、どうしても「運用作業を任せる人たち」という固定観念を生んでしまう。
そこで私は「Ops」という文字を捨て、ProductionEngineerという肩書きに統一した。
これは「私たちはEngineeringチームの一員である」という宣言でもある。

ScaleOps:運用を全エンジニアにスケールさせる

運用専門チームを前提にしないということは、「運用をすべてのエンジニアにスケールさせる」という課題と向き合うことでもある。私はここに大きく2つの投資をした。

  1. Automation:FBARとCobalt

1つめは自動化だ。

  • 私たちはFacebookAutoRemediation(FBAR)という仕組みを作った
    • サーバやサービスの障害を検知し、自動で復旧アクションを実行する
    • 人間が対応すれば膨大な時間がかかる作業を置き換え、1日あたり13600時間分のオペレーションに相当する作業をこなしている
  • キャパシティの追加については、Cobaltというチームとシステムを作り、データセンター立ち上げやラック追加の自動化に注力した

新しいリージョンを立ち上げるときだけは、今でも多くの人が関わる。
しかしそれ以外の多くの作業は、ソフトウェアが代わりに行っている。

  1. Tooling&Instrumentation:可視化と変更管理

2つめはツールと計測だ。

私はよく他社のエンジニアにこう聞く。

「ソフトウェアエンジニアは、あなたがやっていることを理解していますか?そのデータはどう見せていますか?」

多くの人は「このツールのこのグラフが好きなんだ」と教えてくれる。
しかしさらに「それをソフトウェアエンジニアは見られますか?」と聞くと、「いいえ、パスワードがかかっていて見せていません」と答える。

私は「なぜパスワードをかけるのか?」と問い続けた。
Facebookの価値はオープンと透明性であり、それをツールとダッシュボードにも適用したかったからだ。

私たちはいくつかのツールを整備した。

  • 全サーバで動くfb303エージェント
    • 1分または4分ごとにデータを収集し、任意のコマンドを各サーバーにクエリできる
  • 状態を一目で把握できるダッシュボード可視化
    • ただの折れ線グラフではない
    • 緑が正常、赤が異常というより直感的なもの

before:

after:

  • 共通のサービスルーター
    • クライアントとサーバからのエラーを集約し、相関を取りやすくする
    • そのおかげで、エラーの原因がリソース不足であることが瞬時に解ったりする

before:

after:

  • すべての変更を追跡する変更管理ツール
    • いつ、誰が、どのサービスに何をしたかが1箇所で分かる
    • この変更イベントをメトリクスグラフにプロットし、「このスパイクはこのリリースの直後だ」とすぐに紐付けられる
    • インシデントの履歴、コミュニケーション、スクリーンショットをまとめて残し、ポストモーテムをやりやすくする

私たちは問題をすべてオープンにし、重要なものは全社メールで共有している。
依存サービスに問題があるときでも、そのサービスチームに問い合わせる前に、このツールを見れば何が起きていてどう対処しているのかが分かるようにしている。

SROを解散し、全員をエンジニアにする

SROチームは長年にわたり多くの問題を解決してきた。しかしインフラが巨大になりすぎると、1つの集中組織では対応できなくなる。

  • 常に火消しに追われる「ひどい仕事」になってしまった
  • 誰もその仕事に就きたがらなくなった
  • 変化を恐れ、安定を優先するようになっていった

私はある時点で、「SROはその役目を終えた」と気づいた。そしてSROを解散させる決断をした。

正直に言えば、私自身もこの変更に自信があったわけではない。

  • 午前3時に誰も起きておらず、サイトが落ちても誰も気づかなかったらどうなるか?
  • SROが持っていた知識と経験を失ってしまうのではないか?

そうした不安はたくさんあった。

それでも私は、この決断が正しいと感じていた。
SROはエンジニアリングチームを支える存在であると同時に、誰も行きたがらない仕事になっていたからだ。

解散に向けて、私はまずSROメンバーが何をしているかを計測した。そして問題の多いエンジニアリングチームから順にこう問いかけていった。

  • なぜFBARを使っていないのか?
  • なぜもっと良いダッシュボードを作らないのか?
  • なぜアラートが正しく動いていないのか?

こうして少しずつ改善していき、最終的にSROという集中オンコールチームを廃止した。全員がEngineerであり、誰も「ただのOps」ではない状態にした。

とはいえ、ここで油断はできない。
エンジニアリング組織に属しながら、実質的に専任運用担当になってしまう人が再び生まれないよう、常に気をつけなければならない。

Production Engineering Engagement Model

Production Engineeringチームができてから、よく質問されるようになった。

  • あなたたちの役割は何か?
  • ソフトウェアエンジニアリングチームとどう関わるのか?

これは簡単に説明できるものではない。そこで私たちはProduction Engineering Engagement Modelという成熟度モデルを作った。

サービスとチームの成熟度を、3つのステージに分ける。

1つめのステージ: サービスの立ち上げ

  • ProductionEngineering:Bootstrap
  • SoftwareEngineering:Buildout

2つめのステージ: サービスの拡大

  • ProductionEngineering:Scale
  • SoftwareEngineering:InitialDeployment

3つめのステージ: サービスの安定

  • ProductionEngineering:Awesomize
  • SoftwareEngineering:Productionized

このモデルの良いところは、両チームが同じステージに目線を合わせているかどうかがすぐ分かることだ。

もしSoftwareEngineeringがすでにProductionizedの仕事をしているのに、ProductionEngineeringがまだScaleの問題に追われていたら、それはおかしい。そのとき、両者は同じことを見ていないし、同じことに注意を払っていない。

また、チーム同士が敵対していないか、協力できているかも、このモデルを通して見えてくる。
私たちは落ち着いてプライオリティを決める必要があり、そのときにマズローのような階層モデルが役に立つ。
つまり上位のタスクは下位が満たされてから取り掛かるべきということだ。

最後に

最後に、私がまとめとして強調したのは次のようなことだ。

  1. 会社の中で自分が果たすべき役割を見つけること
    肩書きではなく、実際の行動で自分を定義しよう。

  2. チームと足並みを揃えること
    単一障害点にならないようにする。
    全員に「魚を与える」のではなく「釣り方を教え」、自分がいなくても仕事が進むようにする。
    誰かの代わりにやることが、あなたの仕事になってはいけない。

そして、問題が解決できたら、ビーチでテキーラを飲めるようにしよう。

Q&A

Q: 運用組織がない場合、データセンターの構築は誰が？

A:物理的な部分はデータセンター運用チームがいます。ラック一式を提供するインテグレーターもいます。Cobaltシステムがデータセンターの立ち上げの自動化を実際に行います。 新しいリージョンを立ち上げるときは、実際に多くの人間が関与する唯一の部分です。

Q: FBARによってどれだけ運用時間を削減したか数値を紹介いただきましたが、どうやって計測を？

A: 単純に自動化したジョブの実行時間の合計です。人間がそのコマンドをどれだけ早く入力するかなどは計測しておらず、単純に自動ジョブの実行時間。

Q: 開発者をオンコールにしたとき、チームの離職率に対する懸念はありましたか？

A: もちろんです。離職の懸念はあり、実際にその役割をやりたくないといって辞職したりチームを異動した人もいました。 しかし、オンコールを行い実際に運用をするようになって、彼らソフトウェアエンジニアはより優秀になりました。本番環境で何が起こってるかが理解でき、何をするべきか明確になったからです。

Q: 少なくとも2回、大きな決断をされたが、経営陣内でどんな推進力を得て、支持を得ましたか？

A:たくさん会話をしました。最初はソフトウェアエンジニアのリーダーと話しましたが、ほとんどが私のことを頭がおかしいと思ったんです。 でも、とにかく的を射た話を続け、同じことを何度も何度も繰り返し伝えて、理解してくれました。

Q: アプリケーションやサーバーについては説明があったが、ネットワークはどう？

A: ネットワークには一部物理的な結線作業などで自動化できないところがある。一方で、会社としては独自のネットワークスイッチ(OCPモデル)を開発をしている。基本的にはたくさんのAPIを備えたLinuxサーバーだ。そして運用ワークフローの多くをそのスイッチに統合している。 その点で、サーバーと同じようにリモートで管理されたネットワークエンジニアリングとなっていて、ネットワークエンジニアリング組織には自動化に特化したチームもいる。

Q: DevとOpsの壁を無くし、QAを障壁にしない点は素晴らしい。このモデルにおいて、プロダクトマネジメントはこの要素に当てはまりますか？

A:あまり当てはまりません。少なくともFacebookでは。プロダクトチームの多くはPHPやJavascriptを大量に書く仕事です。ProductionEngineeringチームは、UIを担当するプロダクトチームとは直接連携していません。しかし、プロダクトランドと呼ばれるインフラ担当チームがあります。私たちはプロダクトランドのインフラ担当チームと連携しています。

Q:2009年に戻れるとしたら、SROチームを設置していましたか？それとも直接Production Engineeringチームを作っていましたか？

A:当時はProduction Engineeringチームを作ることなんてできませんでした。同じことを何度も繰り返したでしょう。主な理由は、自動化がなかったこと、適切なスキルセットがなかったこと、適切な焦点が定まってなくて、問題が山積みだったからです。

Q:変更管理プロセスについてお話いただけますか？ちょっと気に入らなかったんです。何かが変更されたり本番にデプロイ後に確実に検証を実施し、それを自動化する責任は誰にありますか？

A:私の哲学はずっとこうです。コードを本番にデプロイしたら、おめでとうございます、あなたの責任ですよね。ですから、もしあなたがソフトウェアエンジニアで、それを行うなら、実際にそれを自動化するか、デプロイ中に起こっていることに注意を払う必要があります。それが理想的です。
実際には多くの場合、人はミスを犯します。だから、Production Engineeringチームにとって、デプロイは大きな焦点となる領域です。私たちにとって、ソフトウェアエンジニアがそれを実行できるように多くのツールを開発しています。それが私たちが行なっている自動化機能を多くです。

Q: カスタマーサポートチームとProduction Engineeringチームの関係は？ツールへのアクセスやプロダクションブリッジ、根本原因分析など

A:私たちのカスタマーサポートチームは、Facebook上のユーザーの問題に本当に熱心に取り組んでいます。彼らは様々なツールを駆使しています。一般的に彼らはそれほど詳しい知識を持っているわけではありませんが、カスタマーオペレーション部門のコアメンバーに多数トレーニングをして、これらのグラフや情報を確認できるようにしています。また、別のプログラムもあり、大規模障害のときはインシデントマネージャーが待機し、問題について報告します。カスタマーサポートのチームには報道機関などからたくさんの問い合わせが届いているでしょうから。

Q: Production Engineeringチームが開発している様々なツールをどうやって開発者に認知してもらっていますか？

A: それが今の私たちの最大の課題の1つです。まずは率先して行動すること。実際にこれらのツールを使っているチームがいれば、招いて使い方を示して教えるんです。新しいツールを開発するときはFacebookも使います。社内グループがあり、そこで全員に宣伝できます。Facebook内の広告を使って自社サービスを宣伝しているチームもみかけますね。 まるでドッグフーディングをしているみたいに。

全体を通してコメント

今回はSREcon15の基調講演で、Facebookの物語を見てみました。この要約では省略しましたが、彼の半生(9歳ごろの話)から始まったこの動画はちょっとエモーショナルで、人間の話だったので、要約した文章を読むと味気なく感じてしまいます。(一方で、この動画を要約するのは本当に大変でした。)
オブザーバビリティ関連のツールなど、今では当たり前になっているものを10年以上前にコストをかけて自作している点は、本当に開拓者ですよね。

最後の成熟度モデルについては、ただのスコアシートではなく、今何をやるべきか？を教えてくれる成熟度モデルになっていて
これは他の様々な成熟度モデルに応用が効きそうだと思いました。

次回は、初日のKeys to SRE in SRECon14(SRE@Google)と、今回のNotes from Production Engineering(SRE@Facebook)へのアンサーソング的なセッションを要約して紹介します。

Discussion