絶え間ない問題解決からイノベーションへ: Databricks の Money チームが 1 年で運用負担を半分に削減した方法

昨年、 Databricks Money エンジニアリング チームは刺激的な旅に乗り出し、運用効率をほぼ 2 倍に向上させました。 この変革的な経験を皆さんと共有し、私たちの成功を後押しした具体的な戦略を紹介できることを嬉しく思います。 この記事では、Ops Czar を導入することで運用上の負担が軽減され、同時にエンジニアリング チームの能力が強化された方法について説明します。 実用主義と Databricks の第一原則について説明します。

「団結、強さ」：集団的努力と戦略的効率性が私たちの能力を倍増させた方法

Money チームは、ワークフローやノートブックなどの Databricks 製品の商品化の中心です。 当社は、製品使用量の計測から請求書の計算、顧客へのコストの明確化まで、あらゆる業務を担います。 Databricks が製品スイートと顧客基盤を拡大するにつれ、私たちの業務はますます複雑化し、イノベーションが鈍化するリスクがありました。

この一年は画期的でした。 チームの規模を 2 倍にし、新機能を継続的に導入しているにもかかわらず、最初の 6 か月で運用の健全性が大幅に改善されました。 数字で見ると、私たちの成果は次のとおりです。

• 総運用コストを50%削減
• 緩和までの時間 (TTM; Time to mitigation) を57%短縮
• 解決までの時間 (TTR; Time to resolution) を28%短縮
• モニタリング格差を45%削減
• インシデント量を64%減少
• 保留中の修理項目を28%削減

私たちが成し遂げた劇的な変化は、単なる統計では言い尽くせません。 代わりに、私たちの進歩は、毎週のオンコールのふりかえりで共有される直接的な経験を通じて鮮やかに示されています。

• 1 つの問題に対して 200 件のアラートが殺到する混乱した状況から、ノイズ アラートがまったくない合理化された状態に移行しました。
• 私たちのチームは、実際には緊急事態もないのに数え切れないほどの騒々しいアラートを処理するという絶え間ない忙しさの状態から、毎日数回のチェックのみが必要な、はるかに穏やかな日常へと移行しました。
• 繁忙期でも、オンコール担当者は 「忙しい一週間だったが、それでも何とかなる。自分のプロジェクトに取り組む時間がありました」と報告しています。 以前は 「シフト全体を通して、すべての時間がオンコール作業に専念しています」でした。
• 何よりも説得力があったのは、私たちの成功を要約するフィードバックです:「わずか6か月で昼と夜ほどの違いが生まれました」。

このフィードバックは、ストレスを軽減し、効率を高め、運用環境を根本的に変革して、機能作業とのバランスを大幅に改善し、運用コストを削減する上で、私たちが成し遂げた大きな進歩を強調しています。

「困難に直面したとき、困難に立ち向かうのはタフな人だ」: The Ops Czar

Databricks の急成長に伴い、Money チームはオンコールの負担が重くなり、常にチームの半数以上がオンコール対応の業務に就くことになりました。 これにより、当然のことながら「これは私が作ったものではない。私のせいではない」という被害者意識が生まれ始めました。

チームを被害者意識から解放するにはどうすればよいでしょうか? すでに限界に達しているリソースで、どうすれば状況を好転させることができるでしょうか? ここでの根本的な問題は、どうすれば文化を変えることができるかということです。 従来は、タスクをリスト化し、コストを人週単位で割り当て、チーム間で配分していましたが、これは互換性のあるスキルを前提とした方法であり、運用の健全性の向上などの複雑なタスクには誤った前提でした。 しかし、このアプローチは 主体性 を生み出しますが、 オーナーシップはありません。

限られたリソースで状況を好転させるために、私たちはOps Czarという役割を導入しました。Ops Czar は究極の変革エージェントとなりました。 共有責任モデルから単一の所有権ポイントへの移行により、非効率性が排除され、ROIの高いタスクに重点を置き、決断力のあるリスクテイクが可能になり、成果が大幅に向上しました。

「早めの対策が大きな損失を回避」：積極的なモニタリングとノイズ低減による効率性の向上

モニタリング体制を強化し、過剰なアラートを排除することを目指しました。 自動検出とは対照的に、手動による問題検出は、いくつかの理由でコストが大幅に高くなることがよくあります。

• 検出の遅延：手動で検出された問題は、重大度と影響がすでにエスカレートしている傾向があり、「影響範囲」が大きくなり、より広範な軽減策が必要になります。
• 緩和努力の強化：爆発半径が大きくなると、通常、より包括的でリソースを集中的に使用する緩和戦略が必要になります。
• 予期せぬコスト：手動で検出された問題は予期せぬものであるため、追加のエンジニアリング コストが発生します。

これらのモニタリングギャップに対処することは、コスト削減にとって非常に重要でした。

同時に、モニタリングノイズの問題にも直面しました。 オンコールエンジニアは、大きな問題もなく「一時的な」アラートを簡単に無視できるというのが一般的な考えでした。 しかし、私たちの経験では、そうではないことが分かりました。 オンコール チームのメンバーは人間であるため、労働時間が限られており、注意力にも限りがあります。 一日中頻繁にコンテキストを切り替えると、集中力が低下し、重大なインシデントを効果的に管理することが困難になりました。 軽微な警報、誤解を招く警報、または誤報が多すぎると、全体的な対応能力が弱まりました。

騒々しいアラートの悪影響を認識し、私たちは計算されたリスクを取り、何百ものアラートを排除しました。 我々は、低品質のアラートはアラートが全くない場合と同じくらい有害であると主張しました。 これまでこれらの煩わしさを管理するために費やされていたリソースを解放することで、モニタリングギャップの解消、技術的負債の返済、コードとテストの改良、 CICD自動化などのより優れたツールの開発にさらに注力できるようになりました。

「二度測定し、一度切る」:精度と実用主義の採用

企業文化の観点から、私たちは第一の原則と真実の追求のアプローチを採用し、明確な指針を最前線に置いています。 当社の請求ビジネスでは、「何よりも正確であること」がスローガンとなり、レイテンシーなどの他の考慮事項よりも優先されました。 私たちは、慎重に選ばれたメトリクスを使用して投資収益率を評価し、すべてのオプションを徹底的に評価しました。 私たちの戦略は、段階的に投資し、継続的にデータを収集し、得られた知見に基づいてアプローチを改良し、明確な肯定的な兆候が現れるまで待ってから取り組みを拡大するというものでした。

私たちの最大のハードルは、エンジニアが運用コストに費やす時間、つまりKTLO(Keep-The-Lights-On)コストを定量化することでした。 理想的なシナリオはこれを正確に測定することですが、精度のコストが高いため、より単純な方法を採用することになりました。 各チームメンバーは、運用タスクに費やした日数の見積もりを記録するために、毎週 1 分間を費やしました。 この方法は精度に欠けるものの、3 か月にわたって 20 人の調査結果を集計した結果、貴重な知見が得られました。 この実用的なアプローチは、正確さに対する私たちの本質的な欲求にもかかわらず、啓発的であることが証明されました。 たとえば、私たちが得た知見の 1 つは、KTLO コストとノイズアラートの割合との相関関係でした。 どちらの数値も完璧ではありませんでしたが、相関関係が強いことは明らかであり、ノイズ低減に重点を置くには十分でした。

「ゆっくり着実に進むことが勝利への道」：変革における忍耐力と一貫性の育成

私たちの文化を変革することは、減量の追求に例えることができます：迅速な成功は可能ですが、持続可能な戦略がなければ永続的な成功はまれです。 一生懸命働くだけでは答えにはなりませんでした。永続的な習慣を築くことでした。 習慣の形成はトップダウンで、マネージャーとリーダーが執行者の役割を演じることもできたはずです。 しかし、外的動機付けは内発的動機付けの力に比べると不十分であると主張しました。 チームは、チームのKTLOの苦労をはるかに良い状況に引き上げたOps Czarの貢献を高く評価しました。 信頼と尊敬の念を抱きながら、Ops Czarは共同所有への移行を支持し、次のように強調しました 。「私たちは改善する能力を示しました。私たちの未来は私たちの手の中にあるのです」。

さらに、Ops Czarは説得力のあるビジョンを示しました。オンコール メンバー全員が、ノイズを減らし、モニタリングのギャップを埋め、問題を長期的に解決することで、毎週少しずつでも継続的に貢献すれば、チーム全体の気が散ることが減り、ストレスが減り、時間の経過とともにインシデントに遭遇する回数も減ります。

Ops Czarは、変革に貢献したチームメンバーにスポットライトを当てて称賛するセッションを毎週開催し、彼らの努力がチーム全体に認められるようにしました。 私たちは協力して、業務の健全性指標の上昇傾向を調査し、共通の成功を強化しました。 私たちの進歩の証として、全社的なエンジニアリング賞をチーム全体に授与しました。

「多くの手が軽作業を生む」：オペレーショナルエクセレンスのための集団的努力の活用

私たちは、派遣するオンコール スタッフが、未解決の問題を着信スタッフに日常的に引き継ぐという難しい立場からスタートしました。 この慣行により、インシデントへの継続的な集中と継続的な関与が欠如し、チームは毎週繰り返し断片的な課題に直面することになりました。 これに対処し、チームの総力を挙げて効果的に活用するためには、課題に対する明確なオーナーシップを確立する必要があることを認識しました。

オンコールの移行とレビューのための運用手順を刷新しました。 毎週、発信するオンコールがすべての未解決のインシデントを後任者に引き継ぐようにし、着信オンコールの白紙の状態を目指しました。 週次オペレーションレビューの前に、発信オンコールですべてのサービスヘルスダッシュボードの異常にタグが付けられました。 彼らは、その週のインシデントの症状と根本原因を記録しました。 私たちは、ノイズを減らし、モニタリングのギャップを埋め、ランブックを強化するために、少なくとも 1 つのタスクに取り組むオンコールを提案しました。 私たちは、未解決のインシデントと未解決のフォローアップタスクを毎週一貫してチームに通知しました。 彼らは厳しいように見えましたが、オンコールはシステムの衛生状態を向上させるだけでなく、やることが少なくなることでチームの努力が報われるという相互のメリットをもたらしました。 彼らの貢献の大きな効果は、毎週のレビューで提示される進歩と労力の削減とともに、私たちの文化的な変化を活性化させました。

「鉄は鉄を研ぐ」：知恵の共有によるオペレーショナルエクセレンスの構築

私たちの旅は、単に社内の課題を克服するだけでは終わりませんでした。 私たちは、蓄積された経験、教訓、インスピレーションを活用して、運用慣行を大幅に向上させる一連のツールを開発しました。 オンコール体験を向上させるために、過去の問題の豊富なコンテキストを利用して、新しい問題が発生するたびに関連する過去のインシデントを提案するGenerativeAIレコメンデーションシステムを導入しました。 インシデントの詳細を 1 つのオンコールから別のオンコールに手動で転送するのは非効率的であることを認識し、インシデント再生ビジュアライザーを作成しました。 このツールにより、今後のオンコール スタッフは重要な問題を非同期で理解し、移行プロセスを合理化できます。 さらに、バックログ、ノイズ、モニタリング ギャップが運用の健全性の重要な指標であることを認識し、これらのメトリックを表示するだけでなく、これらの知見を活用して注意が必要な領域に優先順位を付ける包括的なダッシュボードを設計しました。

私たちの開発を姉妹チームと共有したところ、その普遍的な適用性が明らかになりました。運用の衛生、効率、厳密さは、クラウド上でセクターのほとんどのエンジニアリング チームにとって極めて重要です。 この認識により、Databricks 内の約 20 のチームが協力して、統一されたダッシュボードを確立する取り組みが促進されました。 このツールにより、どのチームも運用の健全性にアクセスして分析できるため、組織全体で継続的な改善の文化が育まれます。

「小さな種から力強い木が育つ」：成長と達成の年を振り返って

この一年を振り返ると、ワクワクする気持ちでいっぱいになります。 私たちが達成した改善は目覚ましいものですが、それ以上に重要なのは、チームの考え方と文化の変革です。 かつては気が遠くなるようなオンコールシフトが、誰もが楽しみにしている豊かな体験に進化しました。 正確な請求とコストの最適化という中核的な目標を達成するために、業務を合理化してオンコールの忙しさを軽減しました。 Ops Czarの導入により、運用上の負担をさらに軽減し、よりスムーズな引き継ぎプロセスを採用し、最も重要なこととして、自社チームに力を与えることができました。 実用主義と第一原理を通じて、私たちはこの成功を Databricks の他の多くのエンジニアリング チームと共有することができました。