インターコムのデータインフラストラクチャチームが堅実な原則で増大する需要にどのように対応したか

会社の規模を拡大することは決して直線的なプロセスではありません。 スタートアップがスケールアップすると、チームは新しい要求に迅速に適応する必要がある障害に直面します。

そこで、2020年の終わりにデータインフラストラクチャチームを見つけました。インターコム全体のチームにデータとツールを提供して、洞察を得て重要なプロセスを実行し、かつてないほど需要が高まっていました。 インターコムはここ数年で大きな成長を遂げており、私たちの旅を手伝ってくれる素晴らしい才能のある人をたくさん雇ってきました。 その結果、当社の軌道は急速に変化しました。昨年末までに、当社のチームはかつてないほど高い需要を経験していました。 私たちが使用していたインフラストラクチャ、プラクティス、およびプロセスは、新しい規模で効率的に運用するのに苦労していることに気づきました。

データインフラストラクチャチームは転換点に達していました

チームは、システム内で発生した小さな問題に対処するためにほとんどの日を費やし、根本的な問題を調べてインフラストラクチャを積極的に強化するのではなく、常に事後対応的に作業しました。時間はありませんでした。 マネージャーとして、私はチームの方向性、戦略、専門能力開発に焦点を合わせるのではなく、日常のタスクに飛び込んで手伝わなければならないことがよくありました。 私たちは転換点に到達し、何かを変えなければならないことは明らかでした。

「私たちは、チームを私たちの目標に合わせ、私たちの仕事に集中するための一連の原則を確立しました」

グループエンジニアリングマネージャーのCormacMcGuireがチームに加わったとき、私たちは一歩下がって、私たちを軌道に戻すために何をする必要があるかを検討しました。 知識のサイロ化、継続的なコンテキスト切り替え、重要なシステムヘルス問題の優先順位の低下など、過去にブロックチームで見られたいくつかの問題に気づきました。 これらの問題を解決するために、チームを目標に合わせて作業に集中するための一連の原則を確立しました。

なぜ私たちがインターコムで働く方法に原則が不可欠なのですか？

何年にもわたって、私たちの最高のパフォーマンスを発揮する最も幸せなチームは、彼らがどのように機能するかについて思慮深く慎重に考えると、要求にうまく対処できることを学びました。 原則は、チームを拡大し、チームが自分に合ったことを実行することを信頼しながら、チームを調整し続けるための最良の方法であることがわかります。 私たちの原則は、何がうまく機能し、何が機能しないかについて学んだことから成長します。

これが私たちが解決する必要のある最も差し迫った問題と、それぞれに適用した原則です。

問題1：問題解決よりもスピードを優先する

プロジェクトを迅速に提供することで、お客様、つまりインターコム全体の同僚を喜ばせましたが、解決すべき主要な問題を理解するのに十分な時間がありませんでした。 以前の仮定が正しくないことが判明した場合、またはシナリオが見落とされていることに気付いた場合、完了したプロジェクトを再検討する必要がありました。

原則1：より少なく、より良くする

より少ないタスクで作業することは、コンテキストの切り替えが少なくなることを意味し、問題を完全に理解するためのより深い焦点を可能にします。 チームには、達成するために設定した目標を達成するまで、ソリューションを反復処理するためのより多くのスペースがあります。

「より少なく、より良くする」という原則を採用することは、チームに長期的な利益をもたらすために困難なトレードオフを行うことを意味しました。 まず、他のチームがチェックインする代わりにデータの進捗状況を確認できるように、ステータスサービスを確立しました。 これにより、クエリへの回答に費やす時間が解放され、システムでの作業に使用できるようになり、最終的にはデータ配信が高速化されました。

「それが解決されるまで、私たちは1つのことに集中する必要があり、それを再検討する必要はないと確信していました。 そうして初めて、次のことに進むことができました。」

次に、毎日のELT（抽出、ロード、変換）の信頼性のみに焦点を当てることを選択しました。これは、最新のデータが毎晩プルされ、既存のすべてのデータが更新されるプロセスです。 それが解決されるまで、私たちは1つのことに集中する必要があり、それを再検討する必要はないと確信していました。 そうして初めて、次のことに進むことができました。

問題2：知識のサイロ

私たちのデータインフラストラクチャチームは小規模であるため、エンジニアは通常、プロジェクトに個別に取り組みます。 チームの他のエンジニアが必要なコンテキストなしでコードをレビューすることは困難であり、既存のサービスで問題が発生した場合、システムに取り組んだエンジニアだけが問題を迅速に解決するための知識を持っていました。

「私たちは賢い人々に賢いことを並行してやってもらいました」

そのエンジニアが休暇中だったとき、すべての仕事は止まりました。 私たちのチームメイトはすぐに、その地域の唯一の責任者であることに不満を感じました。 つまり、賢い人たちが賢いことを並行して行うようになりました。エンジニアをよりよくサポートするまとまりのあるプロセスを作成する必要がありました。

原則2：問題をペアにする

すべてのソリューションには、少なくとも2人のエンジニアが取り組んでいます。 2人ではなく1人のエンジニアを割り当てることは、必ずしも結果の効率や品質を2倍にするわけではなく、障害点のリスクを高めるだけです。 プロセスに複数の視点が含まれている場合、プロジェクトは常により良い結果をもたらします。

特定の領域内で質問に答えたり問題を解決したりする人が常にいることを知っていると、個々のエンジニアへのプレッシャーが軽減され、エンジニアが休暇を取ったり、新しいプロジェクトに進んだりするのが容易になります。

問題3：システムヘルスの優先順位が低い

システムの健全性の問題は、あらゆるサービスの運用の一部です。 ただし、新しい問題を優先順位付けして優先順位を付けるための効果的なシステムがなければ、オンコールエンジニアは最初に対処する問題を主観的に決定します。

これらのシステムヘルスの問題が発生したとき、分析データは厳密には顧客向けではないため、最優先事項（P1）としてフラグを立てることに消極的でした。したがって、それほど重要ではないと考えました。 ただし、これらの問題は、システム全体の状態に影響を及ぼし、チームの作業に悪影響を与える可能性がありました。 私たちはそれらを十分に優先していなかったことに気づきました、そして時間とともにそれらはより大きな問題を引き起こすために複合していました。

原則3：システムの健全性は常にP1です

プライマリSLA（サービスラーニング契約）に影響を与えるシステムの問題はすべて最優先事項（P1）になります。 問題にP1としてフラグを立てるアプローチを再考する必要がありました。 P1を緊急の、顧客をブロックする緊急事態としてのみ考えるのをやめ、代わりに重要なプロセスの扇動者として考えるのをやめます。

この原則を実施して以来、私たちは問題にはるかに効果的に対処してきました。 システムヘルスの問題にはP1のフラグが付けられ、オンコールエンジニアが新しいP1の問題を個別に解決するための十分なコンテキストが不足している場合、チームはプロアクティブな作業を一時停止し、問題が完全に根本原因で解決されるまで作業をリダイレクトします。 インシデントはエンジニアリングチームのSlackチャネルに自動的に記録されます。つまり、問題に関する追加のコンテキストや洞察を持っている組織全体の誰もが、問題をできるだけ早く解決するために入力できます。

チームが処理できることについて現実的に考えてください

小さなチームがやりすぎて、焦点を薄く広げすぎて、長期的にはより多くの作業を生み出す重要な詳細を見逃しがちです。

より少なく、より良くし、システムの健全性を最優先事項として位置付けることは、プロセスの他の重要な要素を改善するためのより堅牢な構造を構築し、事後対応ではなく積極的に作業できることを意味しました。 各プロジェクトに2人のエンジニアを割り当てることで、作業方法が変わりました。 インターコムの価値観の1つは「私たちはさらに協力する」ことであり、このアプローチを採用して以来、これは何度も真実であることが証明されています。

私たちの働き方や問題への取り組み方に興味がありますか？ 私たちはあなたと話をしたいです–私たちのオープンな役割をチェックしてください。