Mail.ruのシステムアナリストであるSergey Sharapovは、分析と監視の「向こう側」を探る手助けをしてくれました。 Odnoklassnikiで豊富な経験があり、サーバーおよびネットワーク機器のセットアップからHRのビジネスプロセスの構築に至るまで豊富な経験を持っています。
さまざまな角度から、セルゲイはオドノクラスニキのバックエンドの人生からの成功したエピソードと失敗の両方を自分の目で見たので、私たちは彼にオドノクラスニキの監視サービスの構造、チームワークスキーム、有効性を評価する方法、そして練習から最も記憶に残るイベントについて尋ねることにしました。
-セルゲイ、監視チームの規模、その構造、開発者とのやり取りのポイントについて教えてください。 このスキームの責任者は誰ですか？
セルゲイシャラポフ ：監視チームは8人で構成されています。5人が日勤で働いており、そのうち3人は7:00〜16：00、10：00〜19：00、14：00〜23:00です。そして3人が夜勤で働いています。 午後、ポータルのユーザーアクティビティが増加し、多くの実験が開始されると、2人が交代で働きます。 夜と週末には、1人の従業員がシフトごとに働いています。 デイチームは、発生した異常のより深い分析と調査に取り組んでいます。 監視チームを支援するために、システム管理者が割り当てられ、24時間勤務しており、本当に何かが必要な場合にのみ関与します。 したがって、勤務中であっても、管理者は仕事をすることができます。 勤務中、毎日の監視チームはデータセンターの開発者やエンジニアと直接やり取りします。 通常、夜間チームは勤務中のシステム管理者にのみ連絡し、ダウンタイムまたはその発生の可能性がある場合にのみ管理者を起動します。 すべての夜間のインシデントは、通常、午前中に整理されます。
-監視チームのKPIとは何ですか、その有効性はどのように評価されますか？ 誰が変化を求めていますか？
セルゲイシャラポフ ：移行後、システム管理者は、問題の検出と報告の速度、調査の完全性、問題のエスカレーション、関係者全員が関与しているかどうかの3つの点で監視チームの義務の質を評価する必要があります。 また、登録と調査の品質に関するインシデントのクロスチェックもあります。 終了後の各インシデントは同僚によってチェックされます。 現在、チームが問題を抱えている場所を時間内に把握するために、これらすべての情報を集約および分析するシステムを作成しています。
-アラートシステムは、技術的観点と人間的観点の両方からどのように機能しますか？
Sergey Sharapov ：すべての運用監視は1つのシステムにあります-SmartMonitoring（必要な情報はすべて1つの画面にあります）。ビジネスメトリックの問題とアプリケーションの運用の問題を示します。 Jira + Zabbixと連携して機能する新しい自動車事故に関する通知が表示されます。 Zabbixは問題を検出し、Jiraでインシデントを自動的に作成します。 監視チームと管理者、開発者、およびエンジニアとのすべてのコミュニケーションは、TamTamメッセンジャーで行われます。 多かれ少なかれ重大なインシデントごとに、個別のチャットが作成され、そこで解決されます。 インシデントを作成すると、すべての従業員がいるメインチャットに自動通知が届きます。そこでは、何かに影響を与える可能性のあるすべての実験と作業について書かれています。 自動インシデントはこれらのチャットに該当しません。 これらのインシデントはユーザーに影響を与えず、重大な事態が発生した場合、一般的なインシデントが作成され、自動インシデントがリンクされます。 最も重要なことは、チャットが「読み取り可能」で、スパムが含まれておらず、すべてのメッセージに意味があることです。
-人的要因の影響の最も興味深い事例について教えてください。データベースを削除した人はいますか？
Sergei Sharapov ：もちろん、そのようなケースは発生します...私たちは常に人的要因を最小化するために何かを考え出します。 最も深刻な事件は2013年4月4日に発生しました。 彼については多くのことが言われており、Habréについては別の記事があります。 8年前、私は自分を区別し、数万ドルで機器を「殺した」...私はOdnoklassnikiで働き始めたばかりで、Promiseストアのファームウェアを更新するための訓練を受けました。 私の指導者がSkypeに新しいファームウェアを投げて、コンピューターで更新方法を示しました。 ただし、アレイが長時間再起動から外れるのを待ちます。 これを15台のデバイスで繰り返しました。 ファームウェアはこの機器からのものではないことが判明しましたが、ロールバックする方法がありませんでした。 しかし、物語は私たちにとって幸せに終わりました。 機器の生産準備が整ったばかりだったため、ベンダーが私たちに会いに来て、すべての「デッド」デバイスを無料で交換しました。
また、開発者の1人が、統計で4 TBのデータを削除しました。 理由は、削除コマンドのエラーです。ディレクトリ名の先頭の「$」はエスケープされず、親が削除されました。 しかし、この話はうまく終わり、バックアップがありました。
-ネットワーク上の情報から判断すると、多くの自己記述ソリューションがあります。 これは、Odnoklassnikiが特別なものがないときに登場したという事実によるものであり、すべての最新のソリューションがあなたに適していないためではないのではないかと考えています。 市場を分析していますか？ 人気のどれがあなた自身の成果を置き換えることができますか？
Sergey Sharapov ：私たちはすべての新しいソリューションを常に監視しています。 私たちは多くの会議に出席します。 機器の量に適切なソリューションがあったとしても、それは非常に高価であるか、またはおそらく、それを完了するのに非常に長い時間がかかります。 私たちは、作成したシステムがどのように設計され動作するかをよく知っています。 それらを簡単に管理および開発でき、ニーズに柔軟に変更できます。 私たちは大企業であり、主要製品だけでなく関連製品も作成したいと考えています。 しかし、オープンソースのソリューションを使用しないと言うのは間違っています。 Druidに基づいて作成された統計を保存するためのデータベースについては、11月にHighLoadについてのレポートが作成される予定で、すぐに思い浮かびます。 しかし、必要に応じて機能するために、多くの努力を費やしました。
Odnoklassnikiの実践から技術的な詳細を学びたい場合は、10月のDevOops 2017 PiterカンファレンスでSergeyのレポート「 SmartMonitoring-Odnoklassnikiでのビジネスロジックの監視 」をご覧ください 。 もちろん、彼は一人でそこにいるわけではありません。 きっとあなたは他のレポートに興味があるでしょう：
- Puppet Salt Chef Ensemble：Ansible、SaltStack、Chef、Puppetの比較 （Andrey Filatov、Epam Systems）
- k8の拡張 （ニコライリジコフ、ヘルスサムライ）
- DevOpsの拡張：3つの行為におけるギリシャの悲劇 （Baruch Sadogursky、JFrog、Leonid Igolnik、CA Technologies）
- Kubernetesでの本番アプリケーションのトラブルシューティングとデバッグ（別名The Failing Demo Talk） （Raysang、GoogleおよびBaruch Sadogursky、JFrog）