燃え尽き症候群を防ぐために常時接続状態を変更した方法

記事の翻訳はコースの学生向けに特別に用意されました 「DevOps の実践とツール」.

Intercom の使命は、オンライン ビジネスをパーソナライズすることです。 しかし、機能しない製品をカスタマイズすることはできません。 それがあるべきように。 パフォーマンスは当社のビジネスの成功にとって非常に重要です。クライアントが当社に料金を支払うだけでなく、当社自身も あなたの製品と一緒に。 私たちのサービスがうまくいかなかった場合、私たちは文字通りお客様の痛みを感じます。

スムーズな操作は、ソフトウェア アーキテクチャや日常業務の品質など、多くの要因に依存します。 しかし、常に連絡を取り合っている人が相手からの電話に応答するという事実がすべての原因となることがよくあります。 PagerDuty。 この種のテクニカル サポートは、エンジニアの支援と顧客が製品を購入したときに得られるものを組み合わせた強力な顧客中心のツールとなります。 結局のところ、失敗や間違いはスキルを練習し、複雑な動作メカニズムを理解する良い機会になる可能性があるため、これは学習と成長のための素晴らしい機会でもあります。

勤務時間外に「常時オン」になると、生活に悪影響を及ぼします。

しかし同時に、「常時接続」は生活に悪影響を与える可能性があります。 何かが壊れているという警告に迅速かつ適切に対応できるようにしておく必要があります。 私が個人的な経験から知っているように、たとえ特定の瞬間にページングされていないとしても、「常時接続」であると不安が生じる可能性があります。 このため、睡眠の質は特に著しく低下します。 一日中いつでも定期的にアクセス ゾーンにいると、燃え尽き症候群、無関心、または一般的には二度とコンピューターを見たくなくなるという欲求につながる可能性があります。

インターコムの「常時接続」状態の履歴

Intercom の初期の頃、当社のテクニカル ディレクターである Ciaran は、オフィスの内外でチーム全体に XNUMX 時間 XNUMX 日のテクニカル サポートを独力で提供していました。 Intercom が成長するにつれて、Ciaran を支援するための特別委員会が設立されました。 その後すぐに、新しい開発チームが多くの新しい機能とサービスの作成を開始し、すべての技術サポートの責任を引き継ぎました。

いつでも「待機中」の人が多すぎました。

当時、このアプローチは簡単なことのように思えました。なぜなら、すぐに技術サポート チームを拡張する簡単な方法であり、私たちの価値観と一致し、私たちの状況に適していたからです。 所有感。 結局、何の計画も立てずに、勤務時間外に定期的にクライアントに連絡するチームが XNUMX ～ XNUMX チームになりました。 残りの開発チームには、エラーを引き起こす可能性のある複雑な問題があまりなかったため、呼ばれることはほとんどありませんでした。

私たちは、誇りに思うことができないテクニカル サポート メカニックと、次のような解決したい重要な問題を数多く抱えている状況にあることに気付きました。

• いつでも挑戦する準備ができている人が多すぎました。 当社のインフラストラクチャは、最低 XNUMX 人の開発エンジニアが定休日なしで働く必要があるほど大きくありませんでした。
• アラームと通話手順の品質はチーム間で一貫しておらず、アドホックなプロセスを使用して新規および既存の問題アラートをレビューしました。 ランブックの指示 (問題が通知された場合に従う必要がある) は、その指示が欠如していることでほとんど目立っていました。
• エンジニアが働いていたチームによっては、相反する期待がありました。 たとえば、オンコール シフトや中断された週末に対する補償があったのは、最初のテクニカル サポート チームだけでした。
• 変な時間帯の不必要な電話に対しては、一般的な許容レベルがあるようです。
• 最後に、このタイプの仕事は誰にでも向いているわけではありません。 生活状況によっては、勤務交代が人々に最良の影響を及ぼさないことが時々判明しました。

適切な「常時オン」状態を見つける

私たちは、勤務時間外に各チームのテクニカル サポート業務を実行する新しい仮想チームを作成することにしました。 チームは組織内のチームからの徴兵ではなく、ボランティアで構成されます。 仮想チームのエンジニアは約 XNUMX か月ごとに交替し、数週間を「オンコール」で過ごしました。 幸いなことに、仮想チームを編成するのに十分なボランティアを見つけるのに問題はありませんでした。

その結果、私たちのサポートチームは30人からわずか6、7人に減りました。

次にチームは、ランブック内で問題のアラートと説明がどのようなものであるべきかについて合意して定義し、アラートを新しいサポート チームに転送するプロセスについて説明しました。 彼らは、Terraform モジュールを使用してコード内のすべてのアラートを定義し、すべての変更に対してピア レビューを使用し始めました。 私たちは当直職員にとって非常に満足できる週次シフトの報酬レベルを導入しました。 また、マネージャーのみで構成される第 XNUMX レベルのエスカレーション チームも作成しました。 このチームは、テクニカル サポート エンジニアにとってエスカレーションの単一ポイントとなる必要があります。

このプロセスを確立するまでに数か月の労力を費やしましたが、その結果、待機中のエンジニアは以前のように 30 人ではなく、わずか 6 ～ 7 人になりました。この時間帯は通常、故障が最も多く発生しますが、それ以外の時間帯では、ボランティアによる技術サポートが提供されます。

私たちが学んだこと

仮想テクニカル サポート チームを立ち上げた後、問題の原因を調査したり、機能停止の原因となっている XNUMX つの問題を解決するために集まったりするなど、新しいタスクが大量に発生することが予想されました。 ただし、障害の原因となった要因については開発チームが全責任を負い、その後の対応は通常即座に行われました。 また、エンジニアに時間外の連絡を強制しないように、技術相談タスクが元のチームに差し戻される状況を避ける必要もありました。

時間外の電話件数は月に10件未満に減りました。

私たちのエスカレーションプロセスが正式に使用されることはほとんどありませんでした。 もっと一般的な考えは、エンジニアは現在オンラインのチーム、特にサンフランシスコ オフィスのスタッフによって非公式に助けられたというものでした。 チームワークとその場での解決により、多くの問題が解消または軽減されました。

サンフランシスコ オフィスのエンジニアはフルタイムでチームに加わり、通常の技術サポートを超えた対応を行いました。 多少の諸経費が発生しましたが、サポート チームのメンバーを複数のオフィスに分散させることは、関係を構築し、強化し、全員が協力するテクノロジ スタックについてさらに学ぶための良い方法であることが判明したため、有利に働きました。

Intercom 開発者の仕事はチーム内でより一貫したものになり、サイトでシステム エンジニアであることの利点について自信を持って話すことができます。 採用情報、希望しない限り常に接続する必要はない、と述べています。

データ ストアの安定化と拡張のための基本的な作業に加えて、問題解決に引き続き重点を置いた結果、時間外の通話数は月あたり 10 件未満に減少しました。 私たちはこの数字を非常に誇りに思っています。

当社はテクニカル サポート チームの維持と改善に引き続き取り組んでいます。Intercom が成長するにつれて、現在機能していることが次回スタッフが XNUMX 倍になったときに機能するとは限らないため、決定を再考する必要があるかもしれません。 しかし、この経験は私たちの組織にとって非常に有益であり、開発エンジニアの生活の質、電話への応答の質、そして何よりも顧客のエクスペリエンスを大幅に向上させました。

出所： habr.com