時折、エンジニアリング チームはさまざまな理由でトラブルに見舞われることがあります。 時には、爆発的な成長によりチームが不意を突かれることもあります。 あるいは、オンコールが制御不能になり、5 分ごとにアラートが鳴り響くこともあります。 あるいは、開発チームと運用チームが単に目を合わせなくなっただけかもしれません。
それが新しい問題である場合、修正は簡単かもしれません。サーバーをいくつか追加したり、既知の良いアプリケーション バージョンにロールバックしたり、ピザとビールで皆を集めて誤解を解いたりすることができます。 しかし、多くの場合、問題は時間とともに忍び寄り、突然穴が深くなり、出口が分からなくなることがあります。 LinkedIn では、このような状況に陥ったチームは、しばしば「コード イエロー」と呼ばれる状態を宣言します。
Yellow Alert
コード イエローという名前は交通信号に基づいていると考える人もいますが、より正確には、お気に入りの「スタートレック」シリーズに由来し、よりマニアックにアレンジされているのです。 正確には、宇宙船エンタープライズのクルーが、現在の防御状態を示す方法です。 いずれにせよ、「何かがおかしい、慎重に進まなければならない」ということは明らかです。 両方の比喩に忠実に、私たちはコード・レッドも持っています。 これは、緊急の危機であり、解決するまで全員が1日24時間働くと表現した方がよいでしょう。 コード・イエローは、もう少しのんびりした感じです。 業務時間内であれば、全員が集中的に活動します。 コードイエローは数カ月続く傾向がありますが、コードレッドは数日です。
他の企業ではコードイエローとは別の用語を使用しているかもしれませんが、その効果は同じです：チームは、チーム、したがって会社の成功を確実にするために解決すべき優先事項である深刻な問題を特定したことを社内に伝えているのです。 この能力は、オープンで正直なコミュニケーションの重要な側面であり、健全な文化にとって不可欠でありながら、見過ごされがちな価値でもあります。 問題について話すことは、成功を祝うことと同じくらい、いや、それ以上に重要なことなのです。
This is Not a Failure
Code Yellow を開始する最初のステップは、これが失敗ではないことを理解することです。 チームに修正する必要のある問題があることを認めることは、恥ではありません。 バグは、それを回避するための最善の努力にもかかわらず、発生します。 私たちにできることは、問題を診断し、それを改善することだけです。 私たちが失敗するのは、こうした問題を見て見ぬふりをしたときだけです。 これは、私たちが製造し実行するソフトウェアやシステムと同様に、エンジニアリング チームが互いにどのように相互作用するかに当てはまります。 ほとんどの場合、技術的負債の増加、多くの小さな問題、またはプロセスにおけるブレークダウンなど、ゆっくりと沸騰し、最終的に危機へと蓄積されたために現在の状況に陥っています。
Planning for a Successful Code Yellow
Code Yellowを成功させるには、いくつかの要素があり、また、組織の他の部分からの支持を得るために必要な要素もあります。 コードイエローのきっかけとなった、チームが直面している問題について、明確かつ合意されたステートメントが必要です。 これは、現在の問題が何であるかだけでなく、その根本的な原因に対する現在の理解も含まれる必要があります。 次に、コードイエローを終了するためにチームが取り組む具体的な目標を設定する必要があります。 これらは、従来のSMARTゴール：具体的、測定可能、達成可能、関連性があり、時間を区切ったものであるべきです。 これらの目標があるからこそ、チームはそもそもコードイエローに入ることができ、固定された範囲をカバーし、開放的でないのです。
- コミュニケーション。 発表(問題の記述と終了基準を含む)、成功した結論、および定期的な状況の更新など、コードイエローに関するすべての情報は、より大きな組織に送られるべきです。 これは、あなたの部署かもしれないし、エンジニアリング組織全体かもしれない。
- プロジェクトマネジメント。 すべての大規模プロジェクトと同様に、作業を組織化し、情報を伝達する責任者が必要である。 これは、影響を受けるチームにとって「全員参加」のシナリオであるため、通常、これを支援する専任のプロジェクトマネージャ(PM)を置くと便利です。 このPMは、通常、チームと作業に関する知識はあるが、実行には直接関与しない人物である。
これらの各側面について考え、コードイエローに入ることを決定したら、チームの最初の行動は、終了基準を中心に優先順位を再編成することである。 これはしばしば、四半期ごとの目標を棚上げにすることを意味します。
Space to Breathe
チームがコードイエローに入り、物事を正すために設定された目標に一点集中して取り組むのは良いことですが、チームが成功するためにはこれだけでは十分ではありません。 真の成功のためには、チームを取り巻く全員が状況を理解し、彼らに仕事をするためのスペースを与えなければならない。 ここが健全なエンジニアリング文化が立ち上がるところです。
- 遅れを期待する。 遅延を予期する： 接線チームが影響を受ける最も一般的な方法は、遅延である。 影響を受けたチームに対して行われた要求が、終了基準の範囲内でない場合は、遅延する可能性があることを予期しておかなければなりません。 コードイエローは、その中核に、指定された問題に対処するための優先順位の並べ替えを含んでいます。 外部チームはこのことを考慮し、自分たちのプロジェクトのタイムラインを調整する必要があるかもしれないことを理解する必要があります
- Minimize New Requests: 新しい要求の最小化: 他のチームは、影響を受けるチームに対して、定義された終了基準の範囲外の新しいことを要求することも控えるべきである。 既存の要求の遅延を受け入れることに加えて、これらの要求を最小限に抑えることで、影響を受けたチームは限られたエンジニアリング時間をコードイエローの反対側への移動に費やすことができます。 コードイエローのチームは、目標に到達するために外部の助けが必要であることに気づくかもしれません。 たとえば、トラフィックが突然爆発的に増加した場合、新しいハードウェアのプロビジョニングを加速させる必要があるかもしれません。 このような要請を受ける側になってみると、自分の中の優先順位を変える必要が出てくるかもしれません。
エンジニアリング チームが単独で活動することはほとんどなく、そのチームがうまく機能し、うまく協力することの価値を全員が理解することが重要です。 7554>
Light at the End of the Tunnel
Code Yellow は、かなりの量の優先度の高い作業を表し、それを通して作業することは、しばしばチームにとってストレスになります。 妥当な要求をしている同僚に「いいえ」と言うのは難しいですし、範囲内の作業では、興味深い新機能に時間を費やすことはほとんどありません。 さらに、取り組んでいる問題にグループ間のコミュニケーションの問題が含まれている場合、難しい会話が必要になることもあります。
Code Yellow の究極の目標は、チームを危機から危機へと走り回る反応モードから、適切な大きなプロジェクトに取り組むことができる積極的な状態にすることです。 出口基準を達成することで、エンジニアはより効果的に、主体的に仕事ができるようになるのです。 これは、より強力なチームです。エンジニアは運用業務で強いストレスを受けていないので幸せであり、チームは互いに効果的に話し合っているのでうまく機能しており、顧客はリクエストが自動化または妥当な時間で処理されるので喜んでいます。
LinkedIn がコード イエローを行う方法に類似した社内プロセスがありますか。