ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

DevOpsオンコール:スケジュールの管理方法

私は365日、毎日24時間オンコールの状態でした。

その通りです。当社が サーバー監視 サービスを2009年に開始した時に、自分だけがシステムのことに精通しており、常にオンコールの状態でした。

どのような状況が分かると思います。片手でコードを作って、もう片方の手でプロダクションのアラーとに応答しているような’感じでした。

やがて、より多くのエンジニアがチームに加わり、もう少しプロダクションのインシデントを処理する方法について意図的に対処できるようになりました。本投稿では、チームメンバーの間で、当社のオンコール作業負荷を分散する方法についての詳細及び現在のエスカレーションプロセスの考え方について概説します。

DevOps オンコール

製品の開発と製品に問題がある場合に、生産上のアラートへの応答は、異なりますが、非常に絡みあってます。だからこそ、やらねばならないのです。

私たちは生産での製品のパフォーマンスと開発の努力を遮断した場合、優先順位と結びつかないことが起こりえます。コードの復元は、新機能の開発と少なくとも同じくらい重要です。その点では、生産の問題を開発者やデザイナーを露出することは大きな意味があります。 DevOpsの支持者として、これは良いアイデアだと思います。

待ってください、何ですか?


しかしこれは、非生産的ではないでしょうか?コードを書き込む際の心理状態は、生産アラートに応答する場合とそれほど変わらないはずです。

エンジニア(およびそのことに関わる誰も)が複雑な仕事に取り組んでいる時に、あなたがすることができる最悪のことは、ランダムなアラートを彼らに出してしまうのは最悪なことです。平均的には一旦中断された後に、猛烈にフォーカスできるようになるためには15 分以上かかります。

どのようにして実行するか

この生産性のバランスを適正なものにするためには、細部にわたる検討と綿密なプランニング が必要です。実際には、それは永遠に続く旅のようなものです。当社のように、小さく、成長過程にあるチームにとっては特にそうです。

このことを念頭に置いて、ここで、当社が生産アラートに対処するための現在のプロセスを紹介します。:

第一段階

勤務時間中は、すべてのアラートは、オペレーションエンジニアに行きます。これにより、製品チームが、自らのベストを尽くすために必要な静かな時間を十分に提供します。

勤務時間外のアラートはは、誰にでも(OPSまたは製品を問わず)行く可能性があります。当社では7日ごとにチームメンバー間でローテーションを組んでいます。当社の規模で、各エンジニアは、オンコールが1週間で、8週間オフとなります。誰もが公平な扱いを受けます。

第二段階

エスカレートされた問題は、おそらくコードとは無関係な生産状況に関わっています。そのため、第2レベルのオンコール担当はオペレーションエンジニア間でローテーションを組みます。なぜならば、彼らはハードウェアとネットワークインフラストラクチャーについてより深い知識を持っているからです。

PagerDutyの設定

エスカレーションやスケジュールの管理のために、当社はPagerDutyを活用しています。エンジニアが制限時間内に応答しない場合は(SMSと電話で頻繁15分ごとに通知)、必ず誰かが、電話を取ることができるようになっています。

当社のOPSのエンジニアは、マニュアルのスケジュールを優先する責任があります。誰かが休日か、病気であるか、移動している場合には、ボランティアにオンコールスロットを再配置できるように依頼します。

pagerduty

勤務時間外のアラートは応答者は、オンコールからその後の24時間は休みになります。これは、複数日の夜間に起きていることに対して、社会/健康上への影響に対応するのに役立ちます。

皆と情報を共有する

当社は、業務や製品の責任者と毎週ミーティングを開催しています。その目的は、全員に製品全体の状況を伝え、製品チームが、開発の優先順位付けをできるようにするためです。

私は今はオンコール業務はありませんが(顧客とのミーティングや出張により、オンコールをすることは意味をなさない)、Server Densityのモバイルアプリで(Android and iOS)アラート監視することができます。これにより、当社が使用する他の監視ツールのアプリと一緒にホーム画面上で見ることができます。

皆さんはいかがですか?どのようにdevopsのオンコールのスケジュールを管理しますか?