チェーンソーシリコン大虐殺

義務は、ほとんどの現代の組織の重要な要素です。 結局のところ、問題は午前3時に発生することがよくあります。 しかし、誰が勤務するべきですか？ そして、このプロセスを意味のあるものに整理する方法は？

猫の下を見て、そこにBaruch Sadogursky（ @jbaruch ）とLeonid Igolnik（ @ligolnik ）が1人の失敗した付き添い人についての恐怖物語を語ります。 朝3時にバグを修正しなければならなかったVasyaを覚えていますか？ これはほんの始まりに過ぎません。



この資料は、秋のカンファレンスDevOops 2017でのBaruchとLeonidのスピーチに基づいて作成されました。



だから当番。 例として、1年ほど前に特定の会社で働いていた仮想のVasyaを取り上げます。 今日は金曜日であり、Vasyaが勤務していることが起こりました。 すべてがうまくいきます：ヴァシャは眠っていて、彼の夢は美しいです。

彼は何も疑っていませんが、彼のテクニカルサポートの同僚はクライアントから電話を受けます。 彼は月曜日に非常に重要なデモをCEOに見せなければならないと言いますが、うまくいかないことがあります。 問題を修正する緊急の必要性。 サポートはできる限りのことをすべて行い（オフにしてからオンにすることを推奨）、この問題をアテンダントにエスカレーションします。

Vasyaはプロジェクト全体で単独で勤務しているため、これを行う必要があります。 技術サポートエンジニアが彼を起こして、「何かがうまくいかない、何かが間違っている」という非常に簡単な言葉で問題を説明しようとします。

Vasyaは同僚の話を聞いて、何が起こったかを熟考し、唯一の正しい決定を下します...



サポートエンジニアは腹を立てますが、それでもクライアントに月曜日まで待つように依頼します。 クライアントはこの状況に同意せず、問題をサポートマネージャーにエスカレーションします。 今、彼はヴァシャに電話して、これは深刻ではないと言います：「それでも、問題は重要です、クライアントは心配しています、それは必要です。」 Vasyaは責任者です。 コーヒーとダンス（ログで何かを探す）が必要です。

ログでは、すべてがまったく単純ではありませんでした。 まず、Vasyaは15分間、正しいログにアクセスできる人を探していました。 彼はそれを見つけてログを取得しました。 しかし、どのように？ もちろん、.doc形式でメールを送信します。 Vasyaは責任があり、若く、Wordでログを読み取ります。何も理解されていません。 ただし、ナレッジベースで検索できるキーワードがあります。 Vasyaは約20分間おもしろいことをこなし、おもしろいことすべてを学びますが、現時点では何も必要ありません。

Vasyaは次に何をしますか？ 誰かを探す必要がありますが、Vasyaは若いエンジニアであり、シニアを起こすのは怖いです。 したがって、彼はあなたが同僚、同じ後輩を呼び出す必要があると判断します。



同僚は良き友人であり、悲しみの半分で問題が何であるかを理解し、それを解決し始めます。 2〜3時間の作業の後、彼らはホットフィックスを見つけました。 すぐに本番に提供する必要があります。 しかし、どのように？ 変更管理委員会があり、月曜日に2週間に1回開催されます。 ただし、このオプションは適合しないため、早急に必要です。

当然、実稼働環境にデプロイすることはできません。ルートはありません。 したがって、唯一のオプションは、2つのクラスと説明の段落を含むjarファイルを電子メールで送信することです。 それらの人は本番環境にsshし、そこでWebSphereのこのjarファイルを正しいディレクトリに配置します。 そして今、朝の6時から7時に、ついに達成感を持って寝ることができます。



月曜日に、Vasyaは仕事に来て、珍しい絵を見ます。 CEOはエンジニアリングのVPで叫んでいました。なぜなら、クライアントはCEOが彼に叫んでいたのでCEOに叫んでいたからです。 問題を解決することができなかったことがわかります。

当局には次の4つの質問があります。「金曜日に何が起こったのか」。 「月曜日に上司からこれについて聞いたのはなぜですか？」; 「修正に6時間かかったのはなぜですか？」そして「誰が責任を負うのですか？」 これは彼らの問題ではないと言うOpsが部屋に呼び出されます。 Vasyaと他のメイドは部屋に呼ばれ、「何も効かなかった」とも言われます。 ジャガイモのこのゲーム全体は昼食まで続きます。

夕食を食べる時が来たので、決定は「OK、それはそれ自体で壊れています、誰も責めることはありません。」 物語の終わり。



小さなデブリーフィングを準備しましょう。この悪夢を通り抜けて、すべての質問に答えてみましょう。

誰が勤務するべきか

システム管理者（またはよりファッショナブルな単語-SRE）が任務を果たすことができます。 彼らは数年前からこれを行っており、すべてがうまく設定されています。 DBAは勤務中、メッセージングに従事している人は勤務中です。 運がよければ、NOC（ネットワークオペレーションセンター）が勤務しています。これは、これらすべての人が同じ部屋にいるときです。 彼らには、困難な状況で何をすべきかを伝えるRunbookがあります。



これらの人々のすべては明らかであり、彼らは当直のプロです。 しかし、残念なことに、DevOpsには方程式の2番目の部分があり、実際に勤務したくありません。 第二部の作り方は？ はい。そして、プロは義務の重要性を認識する必要があるため、強制する必要があるかどうか。

人々が勤務中になりたくない理由は2つあります。 1つは次の場合です。



すべてが悪いとき、誰も当直したくありません。 この問題の解決策は非常に簡単です。



あなたは良いコードを書く必要があります、すべては簡単です。 しかし、これも学ぶ必要があります。 新しい質問が発生します：「学習方法」。 ソケットに指を入れる必要があります-#painisinstructional。 痛みが助けます。



義務はそれ自体でコードの品質を改善します。 月曜日の同じVasyaは、間違いを修正して、エラーを探して別の夜に座らないようにします。

当直の障壁

勤務中、そこにあるべきではないいくつかの障壁があります。 Vasyaの金曜日の大失敗を見てみましょう。 彼がどのようにワード文書のログを読んだか覚えていますか？



マイクロソフト製品は誰もが愛していますが、現代の世界ではそれができません。 ログについては、誰もが理解すべき明らかなことがあります。 主なポイントは、これらの問題を解決するツールの数です：Logstash、Loggly、Sumo logic、Kibana。 それらを使用する必要があります。

アクセスの質問に戻る：なぜログへのアクセスを許可しないのですか？ 答えは機密データです。 クライアントは、データを漏洩から保護することを約束されました。 これは、ログを誰にも表示できないこと、またはデータマスキングの機能を備えたシステムを使用する必要があることを意味します。 彼自身が個人データを隠し、必要なアクセスレベルのない人には表示しません。 今日のログ解析ツールはすべて、この機能を備えています。

これらのツールのもう1つの利点は、「貧しい人々のための監視」を構築できることです。 たとえば、ログで、一定数のエラー（キューがいっぱいなど）を確認した後、アレルギーを引き起こすことができます。

誰が問題の重要性を判断しますか

問題を解決するために理解する、勤務中に就寝する、または緊急に実行する方法は？ 誰が重症度を処方しますか？ 誰が問題の重大性を判断しますか？ サポートを解決します。 なんで？ なぜなら、サポートには問題のビジョンがあるからです。 彼はすべてがどれほど悪いかを知っています。

さらに、今日、ほとんどすべての企業が「継続的デリバリー」の原則に基づいて作業しているため、すべての顧客がすべての機能を同時に（そして同時にバグを）受け取ります。 「何かがそこで機能しない、クライアントにとっては問題ない」というバグがあるとします。 同時に、サポートは問題に関する何百ものアラートを確認します。これは明らかに深刻です。

クライアントは、問題の重要性を判断することにも関与しています。 しかし、問題があります-クライアントは、彼の小さな問題が修復されると常に信じているわけではなく、最も重要視しています。 重大度は操作ツールとして使用され始めます。 しかし、重大度の定義が正しく構築され、クライアントがSLAとは何かを理解している場合、通常これは起こりません。 これは、顧客が本当に非常に重要なものと単に重要なものを理解し始めるときの相互学習プロセスです。

製品メーカーは常に問題の背景を理解しているわけではないため、顧客に重要性を示す機会を与える必要があります。

SLA-1日以内に対応とソリューションを保証しますが、より高速にすることができます。 これも、コンテキストに依存します。

組織の課題

Vasyaは最後まで問題を理解していませんでした。 もちろん、彼は目が覚めたばかりで、技術サポートの同僚も説明が不十分でした。 これは、チケットという1つの方法でのみ処理されます。 チケットは、それが何であるかを示す参照番号です。 これは、Vasyaにとって必要です。電話ではなく、サポートがVasyaに「チケット管理システムを開いてチケット番号42を参照してください」と伝えることができるからです。 これはいくつかの理由で必要です。 まず、Vasyaは、眠い状態の同僚の話を聞く代わりに、目を覚まし、チケットを読み、これがどれほど重要かを理解します。 第二に、複数の問題があるかもしれません。

全体像に影響を及ぼす別の困難があります：Vasyaを見つける必要があります。 サポートは、Vasyaが今日勤務中であることをどのように知っていますか？ 彼がVasyaを知らない場合はどうなりますか。 適切な人を見つけることが重要です。 ソリューションは、技術者、生産者などのさまざまなプレフィックスを持つVirtual Extensionです。 まあ、または他の、より洗練されたシステム。 このソリューションを使用すると、深夜にどこに電話をかけるかを推測する必要がなく、すべてが自動的に切り替わります。

さらに便利なのは、Slack、Telegram、Skype、その他の場所でのエスカレーションチャットです。 チャットのタイトルは、同じチケットの番号です。 このチケットでの適切なユーザー間のすべての通信は、このチャットルームで行われます。 このようなチャットの最も便利な機能の1つは、しばらくして作品に参加する人に何も伝える必要がないことです。 すでにどのような決定が下されたかについて簡単に読むことができます。

さて、仮想電話ブリッジは、火災の場合の集合場所と比較することができます。問題が発生した場合、誰もがどこに行くべきかを知っています。 ちなみに、ZoomやBluejeansのような最新のシステムでは、必要な機能はすべて既に組み込まれています。

エスカレーションパス

彼らはひどいので、Vasyaは主を呼ぶことを恐れていました。 それをどうしますか？ エスカレーションパスについて説明しましょう。 誰がいつ誰が目を覚ますか、仕事から離陸するかを常に知っていなければなりません。 これは、誰にとっても完全に明確でなければなりません。目を覚ます人と目を覚ます人にとって。 また、最初のパスが機能しなかった場合の呼び出し先を知る必要があります。 適切なエスカレーションパスは、会社のCEOに至るまで続きます。



CEOからの連絡が必要です。 彼は重大な問題を認識していなければなりません。

使いマネージャー

次の興味深い役職は、通話中のマネージャーです。 彼は技術者である必要はなく、問題の解決に参加する必要はありません。 まず、深夜のVasyaは、クライアントに有用なことを伝えることができません。 デューティマネージャーは、このような状況を支援できます。 さらに、彼は調整、困難な状況でのプロジェクト管理、リソース管理に従事できます。 結局のところ、作業はスムーズに進むはずです。

生産へのアクセス

Vasyaに本番環境へのアクセスを許可する必要がありますか？ 結局のところ、すべてが優秀なエンジニアであるわけではなく、私が学びたいと思わない特定のことがあると、顧客は怒ります。 これは、展開プロセスを使用して解決されます。 プロセスが正しく構成されている場合、Vasyaはボタンをクリックできます。その結果、生産コードが無効になります。 通常の連続配信パイプラインがある場合、これはほとんどの場合自動的に実行できます（すべてのテストに合格します）。 そうでない場合、多くの企業では、上級エンジニアまたはマネージャーが決定を下します。 彼はレビューを行い、コードのリスクを評価し、決定を下します。

また、修正プログラムが登場する前でも、トラブルシューティング用の文書化されたツールが必要です。 勤務中の最も一般的な問題の1つ：彼は、デバッグをオンにする方法、またはログのレベルを変更する方法について考え始めます。 同時に、他のすべてに問題はありません。 問題の解決策を文書化することをお勧めします。

職務の変更

それでは、通常1週間かかる義務のプロセスについて話しましょう。 ある時点で、変更する必要があります。 効率的に変更するには、特定の時間にこれを行う必要があります。 すべてを明確に計画する必要があり、問題を職務上の次の人に効果的に伝えることができることが望ましい。 多くの企業では、これは標準的な集会として行われるか、係員が小さな雑誌を保管するページが作成されます。

その他の問題

対処する必要がある他のさまざまな問題があります。 それらの1つは、生産へのアクセスの認証です。 人が何が可能で何がそうでないかを理解していることを示すために、基本認証を実施することをお勧めします。

翻訳する方法は？

しかし、これらをすべて会社に持ち込むにはどうすればよいでしょうか？ これには時間がかかることを理解する必要があります。



勤務中の年長者から始める必要があります。 彼らは経験を持ち、何をどのように修復するかを知っています。 主の問題は少なくなりました。ログなどにアクセスできます。

小さなチームで始めることをお勧めします。 チームが既に大規模な場合は、その中に小さなチームを作成する必要があります。 さらに、すべてがうまく機能し始めたら、残りを恥じることができます。

結論

主なものに移ります。 私たちの技術者は技術に恋をしているという事実にもかかわらず、最も重要なことは、会社で使用されている製品や技術ではなく、「私は製品の改善プロセスに関与している」という担当者の感覚です（まあ、または義務そのもの）。 多くの人々はあなたが勤務している必要があることを理解していますが、改善を見たいと思っています。 人々は、彼らと彼らの改善のおかげで、物事が良くなっていることを認識すべきです。

PS

ドライブという本をお勧めします。 これは、私たちのような職業で働く人々の動機に関する本です。 この動機は3つの主要な要素で構成されており、（ネタバレ）それらのどれもお金ではありません。

すでに今週の日曜日に、BaruchとLeonidはサンクトペテルブルクで開催されるDevOops 2018でレポート「#DataDrivenDevOps」を配信します。 さあ、たくさんの興味深いことがあります。レポートはこちら、 ジョン・ウィリスはこちら、BoFとカラオケのパーティーはこちらです。 あなたを待っています！