開発エスカレーションプロセス（廃止）
プロセス廃止 - 1月5日付で有効 開発エスカレーションプロセスは1月5日付で廃止されました。専門家サポートにはTier 2 オンコールプログラムをご利用ください。 プロセス変更 開発エスカレーショ …
開発エスカレーションプロセスの一般情報
このページについて
このページでは、インフラストラクチャエスカレーションプロセスの背景、目標、成功基準、実装の詳細、およびQ&Aについて説明します。
背景
歴史的に、GitLab.com のお客様に対してサービスレベルを一貫して維持することには課題がありました。このGitLab.com パフォーマンス低下サマリードキュメントでその影響をご覧いただけます。
この問題は、ビジネスが急成長し、ホスト型SaaSのユーザーベースとワークロードが指数関数的に増加する際に、GitLabに限らず起こりうることです。その結果、ビジネスの成長に対応して、お客様がGitLabから引き続き最高のサービスを体験し続けられるよう、また私たちのビジネス成長の勢いを維持・強化するために、私たちの働き方にも対応した変更が必要になります。
このことと最近の運用インシデントを踏まえ、開発チームのDevOpsプラクティスを強化し、インフラチームと連携してGitLab.comをスムーズに運用し続けることが明確になりました。
プロセス
GitLab.com の問題をより迅速に解決するため、開発チームはオンコールローテーションを確立し、私たちが提供するプロダクトに責任を持ちます。平日は2020年9月/10月のパイロットを実施しており、Slackチャンネルのエンジニアがオンライン時（最後にエスカレーションされた順）に通知を受け取ります。週末（ほとんどの人がオンラインでない時）は、カバレッジを確保するためにタイムスロットを埋める必要があるスプレッドシートを使用してエスカレーションします。パイロットプログラム期間中は、スプレッドシートはバックアップとして使用されます。
インフラチームは引き続きフロントラインで最初の防衛ラインの役割を担い、運用上の問題をより迅速かつ効率的に解決するために開発エスカレーションを開始するかどうかを判断します。
この新しいプロセスでは、ローテーションスケジュールに基づいて開発エンジニアがオンコールを担当する必要があります。詳細については、オンコールプロセスの詳細説明を参照してください。
目標
オンコールプロセスは、以下の目標を念頭に置いて設計されました:
- 明確な期待値、責任、説明責任。
- インフラチームをサポートするための完全な24時間365日体制のカバレッジ。
- SLOを確保するための階層的なエスカレーション。
- 1日あたりのエンジニアのオンデューティ時間のバランス。
- 1年間を通じて各個人の負担を最小化。
- ジャストインタイムでの調整の柔軟性。
- エンジニア自身が自分の勤務スケジュールをコントロールできること。
成功基準
- インフラエスカレーションへのタイムリーな対応に関する開発部門のSLOを満たす。
- オンコールエンジニアが燃え尽きない。
- 計画された開発作業への影響を最小化する。
実装
開始方法と継続的な運用については、上記のプロセスセクションを参照してください。イテレーションの精神に則り、実践を通じた学習に基づいてプロセスは継続的に調整・改善されます。
非同期のレトロIssueが登録され、すべての参加者はいつでもIssueにフィードバックを入力することが推奨されます。3ヶ月のチェックポイントでレビューを実施し、次のステップを決定します。
感謝
サポートローテーション、特に週末のサポートを担当してくれる方々への感謝を示すことが重要です。四半期ごとに、エンジニアリングディレクターとマネージャーは前の四半期に週末サポートローテーションを担当したすべての人（各人の名前と担当したローテーション数を記載）への感謝メッセージを#Thanks Slackチャンネルに書くことが推奨されます。また、マネージャーも認識できるよう、そのマネージャーを@メンションすることも推奨されます。
これを行う理由:
- 各エンジニアが週末のサポートローテーションをどれだけ担当したかは、長期間にわたってレビューしないと容易にはわかりません。
- ドキュメント化されたプロセスの一部でない限り、長期間にわたって定期的に実施することを忘れがちです。
- 自動化ではなく手動で行うことで、より個人的なものになり、真の感謝を示すことができます。
Q&A
Q: なぜ開発エンジニアのオンコールが必要なのですか？
A: 最近のパフォーマンス低下インシデントの調査において、問題の根本原因を特定し、健全な解決策を開発するためには、より深いプロダクト知識が必要であることが明らかになりました。インフラエンジニアはほとんどのインシデントに対応するのが得意ですが、実装の詳細に関する深い洞察が必要な問題の場合、短期的な回避策や一時的な修正を迅速に提案できるのは開発エンジニアです。
Q: ワークライフバランスへの影響を最小限に抑えるためにどのような取り組みがされていますか？
A: どのエンジニアも現在働いている時間より多くの時間を求められることはありません。オンコール中に費やす時間のほとんどは、通常でも勤務している日時になります。オンコール時間の約25%は通常勤務しない日に充てる必要がありますが、エンジニアが自分でいつ担当するかを選択でき、総勤務時間が増加しないため、その影響がなるべく最小化されることを願っています。また、個人的な緊急事態の場合は代替者を見つけることもできます。
Q: スケジューリングを「スマート」にして、通常の勤務時間内にいるエンジニアに動的にページングできますか？
A: はい。平日はPagerslackを使用して、Slackでオンラインのエンジニアに基づいてページングします。週末/祝日は、ほとんどの人が定期的に週末勤務しないため、スプレッドシートが依然として必要です。
Q: ボランティアベースにできますか？
A: 理論的には可能です。ただし、いくつかの点を念頭に置く必要があります。
- ボランティアの大多数が近いタイムゾーンに集中したらどうなるか？
- 事前にすべてのボランティアを募集した場合、非常に小さなグループになってしまったら？
- 次のローテーションや翌月前など動的にボランティアを募集する場合、継続的な管理オーバーヘッドが発生し、抜け漏れが生じやすくなります。特定の週にボランティアがいない場合はどうなるか？常に同じ少人数グループになってしまったら？
週末と祝日については、現在ボランティア優先モデルを採用しており、空いているシフトは割り当てられます。エンジニアが自分のスケジュールをより管理できるよう、シフトへのボランティア参加を推奨しています。
Q: ページングされたエンジニアが専門知識を持っていない場合はどうなりますか？
A: プロセスに階層的なエスカレーションプロセスが定められています。また、最初の対応がすぐに解決策を提供することを意味しないことも明記されています。
代替案として、同様の方法でドメイン専門家をオンコールにすることも検討しました。これはより多くのエンジニアと小規模なオンコール部門が必要になり、より頻繁なシフトとエンジニアあたりのオンコール業務が増えることになります。オンコール業務を最小化するトレードオフが選択されました。
Q: これはバックエンドエンジニアとフロントエンドエンジニアの両方を対象としていますか？
A: 最近の問題のほとんどがバックエンドの知識を必要とするという事実を考慮して、最初のイテレーションではバックエンドエンジニアのみが対象となります。長期的には、プロセスが調整され問題のパターンが十分に理解された後、フロントエンドエンジニアも参加することがあります。
Q: 開発部門以外のエンジニアはローテーションから除外されているのはなぜですか？
A: このローテーションは、私たちが提供するプロダクトの責任を持つ、プロダクト開発に直接携わっているエンジニアへのアクセスを提供することを目的としています。 他の部門のエンジニアは異なる責任を持っています。たとえば、インフラ部門のエンジニアはGitLab.com のスケーリングと信頼性の側面に集中する必要があり、GitLab.com のSLO達成に向けて取り組むことが職務記述書の一部となっています。エンジニアリング生産性部門のエンジニアはツールの提供に注力しており、これはプロダクト開発からやや離れています。
Q: 候補者の面接時にオンコールについて聞かれた場合、どう答えますか？
A: インシデント処理モデルの全体像を説明し、開発エンジニアがGitLab.com の運用インシデントの解決を支援するためにオンコールになる可能性があることを候補者に伝えましょう。 通常、インフラチームがフロントラインで最初の防衛ラインの役割を果たします。インフラチームが開発エスカレーションが必要と判断した場合にのみ、開発エンジニアが呼ばれます。
Q: 職務記述書は更新されますか？
A: エンジニアリングリーダーシップチームがタレントアクイジションチームと連携してこの件に取り組みます。職務記述書に変更がある場合は、すべての面接担当者に通知されます。
Q: 地域の法律がオンコール業務を制限または禁止している場合はどうなりますか？
A: 懸念点や地域の法律および規制に曖昧さがある場合、すべての人が地域の法律および規制情報をマネージャーと共有するよう推奨され、さらなる確認が得られるまでスケジュールに入れられません。エンジニアリングリーダーシップチームも法務部門とPeopleOpsと連携してこの点について確認します。私たちはGoogleドキュメントにルールのリストを管理しています。
Q: PagerDutyの使用は検討されましたか？
A: はい、検討しました。Chatopsボットを強化するための作業があるため、最初のラウンドの実験では Slack を使って軽量に保つことにしました。
Q: オンコール中の既存業務への期待は何ですか？
A: オンコール中は既存業務を事実上停止することが期待されます。マネージャーはオンコールエンジニアが利用できないことを前提として計画を立てる必要があります。進行中のインシデントがないために進捗できる場合は歓迎されますが、オンコールリクエストがあった場合は業務を停止しなければなりません。
Q: オンコールシフトの境界時に未解決のエスカレーションがある場合の期待は何ですか？
A: ガイドラインセクションの箇条書き7（リレーハンドオーバー）と同様に、これまでのステータスと調査内容をまとめてから引き継ぎを行います。
Q: Slackで#infra-escalationからの通知を特定の時間帯（特にAPACの0400-0700時など）のみトリガーするよう設定できますか？すでに業務時間外に多くのpingを受けていますが、現在は「おやすみモード」をオンにしているため起きません。
A: モバイルアプリで通知をカスタマイズできるようです。このガイド（Androidデバイス）をご確認ください。
通知画面のチャンネル固有の通知設定を通じて、特定の時間帯（例: 午前4時〜8時）にエスカレーションチャンネル以外のすべてのチャンネルをミュートすることで、ノイズを減らしエスカレーション通知のみを受け取ることができます。
Q: 何らかの補償（給与、休暇など）の概念はありますか？
A: オンコール業務は他の成果物と同様に考えることができます。追加の時間を費やすことを意味しませんが、現在よりも望ましくない時間帯の勤務が数時間発生します。これを補うための報酬変更は予定されていませんが、望ましくない時間帯を選択して期待を超えた人への自由裁量による報奨を検討することがあります。
Q: オンコールエンジニアへのエスカレーション量はどのように測定されますか？「ホット」な問題の修正のためにワーキンググループが必要な時期を知るための閾値が設定されていますか？
A: 手動でカウントして、Infra/Devミーティングでボリュームをレビューしましょう。これもボードに追加できます。
Q: 新しいオンコールの勤務時間について議論しており、期待されるシフトがありますが、これはハンドブックのこの記述に基づく非オンコールからの方針転換です。/handbook/values/#measure-impact-not-activity これは意図的な方針転換ですか？
A: これは方針転換ではありません。エンジニアはローテーションの全体的なカバレッジ目標が達成される限り、いつ働くかを選択できます。インパクト対アクティビティの方針は、機能の提供に基づいています。オンコールは、いつでも発生し得るすぐに対処する必要がある運用上の問題に対処することです。そのため、両方の方針は合致しています。
Q: 本番の問題を効果的にデバッグするために、開発者は本番システムとメトリクスへの拡張アクセスが必要な場合があります。開発者のオンコールは、本番システムの直接デバッグなしに純粋にコンサルタティブな目的のみを想定していますか？本番システムへのアクセスが必要な場合、どのようにオンボーディングされますか？
A: 最初のイテレーションでは、コンサルタティブなプランであり、コード変更が必要な場合はオンコールエンジニアが変更を行います。直接デバッグは必要とされておらず、インフラ部門が進捗のために本番の問題をオンコールに効果的に伝えることが期待されています。現時点では本番環境へのオンボーディングは計画していません。
Q: このプロセスが最近の障害時に導入されていた場合、大幅に早く解決できていましたか？つまり、現在の最大の問題はサポートエンジニアを見つけるまでの時間ですか？
A: パフォーマンス低下の一部として示された障害のチャート（上記リンク参照）を見ると、6月5日、7月1日、3日の障害が確認できます。6月5日に問題を把握し対処していれば、7月1日の低下を防げた可能性があります。7月3日は障害半分、攻撃半分です。そのため、ここでもある程度の影響を最小化できた可能性があります。これらの低下に関連した時間も長く（7月1日で540分）、削減できたでしょう。
Q: これは単に問題への対応速度ではなく、インシデントを解決まで見届けるという規律に関するものではないでしょうか？オンコールプロセスは後者に対処しているように感じますが、前者には対処していないように思えます。
A: 実際には両方であり、両方に対処するために取り組んでいます。また、Infra/DevのIssueボードを追加して解決に向けた取り組みを追跡し、適切な優先度と重大度があることを確認しています。オンコールエスカレーションは最終的にこのボードのフォローアップ項目につながる可能性が高いです。このページで説明が記載されています。
Q: インフラメンバーはどのようにしてエンジニアに国際電話をかけられますか？
A: Zoomは低料金での国際電話発信をサポートしています。進行中のZoom通話内からInvite > Phoneで発信できます。これはエンジニアに進行中のエスカレーションを通知するためだけの素早い電話に使用されるため、GitLabのコストは非常に最小限になります。
