緊急事態ワークフロー
ASE のアカウントからの緊急事態
Assigned Support Engineer (ASE) を持つアカウントは、あなたが対応可能なとき または 対応不可能なとき のいずれかに緊急事態を発動できます。
いずれの場合も、あなたは恒久的にオンコール状態にあるわけではないため、オンコールエンジニアでない限り緊急事態を引き受ける必要はありません。ただし、このようなときには、あなたが顧客の状況、問題、目的について最も深い知識を持つサポートエンジニアであることを思い出すことが重要です。したがって、このような緊急事態でオンコールチームと協力することにより、GitLab サポートと顧客の両方にとって何時間ものトラブルシューティングを節約できるかもしれません。
ASE のためのプロセス
対応可能なとき
オンコールエンジニアからあなたに緊急事態の通知があり、あなたが対応可能であるか対応可能になれる場合は、オンコールエンジニアと並行して作業し、顧客の状況を安定させてください。これには次のいずれかが含まれることがあります。
- 緊急事態の DRI を引き継ぐ
- 一定時間、緊急事態をシャドウイングする
- Slack で非同期に緊急事態のトラブルシューティングを行う
- オンコールエンジニアが顧客と協働するため、または顧客の環境を理解するために役立つ重要な情報を提供する
提供できるどのような支援もありがたく受け止められます。
対応不可能なとき
仕事に戻ったときに、自分が対応不可能だった間に緊急事態が発生していたのを目にしたら、何が起こったかをキャッチアップし、顧客に連絡して次のステップを話し合ってください。
自分が不在になることが分かっている間に大きなタスクが計画されている場合は、プロアクティブに、オンコールエンジニアに準備をしてもらってください。
プロアクティブであること
時間外に緊急事態につながる可能性のあるタスク（今後のアップグレード、移行など）が計画されている場合は、計画されている内容、発生する可能性のある問題（分かっていれば）、推奨される解決策の概要を作成しておくと有用です。トラブルシューティング中にオンコール SE が必要となるかもしれない他のアカウント固有の情報（アーキテクチャ情報、問題など）がある場合は、タスクに先立つ既存のチケットの内部ノートに記載し、オンコールエンジニアが見られるようにしてください。
bfd74782)