モニタリング
技術サポートは、「なぜ...サイトが再びダウンしたのか？」という内容のアプリケーションが届くまで待機しません。 サイトがクラッシュした1分後にサポートが既に問題を認識し、解決を開始するはずです。 しかし、このサイトは氷山の一角です。 その可用性は、最初に監視されるものの1つです。
オンラインストアの商品の残りがERPシステムから来るのを止めた状況はどうですか？ または、顧客の割引を計算するCRMシステムが応答しなくなりましたか？ 同時に、サイトは機能しています。 条件付きZabbixは200の応答を取得します。 勤務中のシフトは監視からの通知を受け取らず、ゲームオブスローンズの新しいシーズンの最初のエピソードを喜んで検査します。
多くの場合、監視はメモリ、RAM、およびサーバープロセッサの負荷の状態を測定することによってのみ制限されます。 しかし、ビジネスでは、サイトで商品の入手可能性を取得することがはるかに重要です。 クラスター内の1つの仮想マシンが条件付きでドロップされると、トラフィックがその仮想マシンに流れなくなり、他のサーバーの負荷が増加します。 会社はお金を失うことはありません。
したがって、サーバー上のオペレーティングシステムの技術的なパラメーターを監視することに加えて、ビジネスメトリックを構成する必要があります。 お金に直接影響する指標。 外部システム（CRM、ERPなど）とのさまざまな相互作用。 一定期間の注文数。 成功または失敗したクライアント認証およびその他のメトリック。
外部システムとの相互作用
年間売上高が10億ルーブルを超えるWebサイトまたはモバイルアプリケーションは、外部システムとやり取りします。 前述のCRMおよびERPから始まり、販売データを外部のビッグデータシステムに転送して、購入を分析し、顧客に間違いなく購入する製品を提供します（実際にはありません）。 このような各システムには独自のサポートがあります。 多くの場合、これらのシステムとの通信は痛みを引き起こします。 特に問題がグローバルであり、異なるシステムで分析する必要がある場合。
一部のシステムは、管理者に電話または電報を渡します。 マネージャーへの手紙を書くか、これらの外部システムのバグトラッカーに行く必要がある場所。 1つの大企業の場合でも、さまざまなシステムがさまざまなアプリケーション会計システムで機能することがよくあります。 アプリケーションのステータスを追跡することが不可能になる場合があります。 1つの条件付きJiraでアプリケーションを受け取ります。 次に、この最初のJiraのコメントに、タスクへのリンクを別のJiraに配置します。 アプリケーションの2番目のJiraでは、誰かが既に問題を解決するために条件付き管理者Andreiに電話する必要があるコメントを書いています。 などなど。
この問題の最善の解決策は、たとえばSlackに通信用の単一のスペースを作成することです。 外部システムの運用におけるすべての参加者の招待。 単一のトラッカーと同様に、アプリケーションを複製しないようにします。 アプリケーションは、アラートの監視からprodのバグの解決策の表示まで、1か所で監視する必要があります。 これは非現実的であり、歴史的に発達しているため、あるトラッカーで動作し、別のトラッカーで動作すると言うでしょう。 さまざまなシステムが登場し、独自のITチームが独立しました。 私は同意するため、CIOまたは製品所有者のレベルで問題を上から解決する必要があります。
対話する各システムは、優先度によって問題を解決するための明確なSLAを備えたサービスとしてサポートを提供する必要があります。 そして、条件付き管理者のアンドレイがあなたのために時間を持っているときではありません。
男-ボトルネック
プロジェクト（または製品）の全員が、休暇中に当局がけいれんを起こすような人物を持っていますか？ devopsエンジニア、アナリスト、開発者のいずれでもかまいません。 結局のところ、devopsエンジニアだけが、どのサーバーにどのコンテナーがインストールされているか、問題が発生した場合にコンテナーをリロードする方法、そして実際に複雑な問題はそれなしでは解決できません。 アナリストは、複雑なメカニズムがどのように機能するかを知っている唯一の人です。 どのデータストリームがどこに行きますか。 どのサービスに対するリクエストのどのパラメータで、どのサービスに回答を受け取りますか。
ログにエラーがある理由をすぐに理解し、製品の重大なバグをすぐに修正するのは誰ですか？ もちろん同じ開発者。 他にもありますが、何らかの理由でシステムのさまざまなモジュールがどのように配置されているかを理解しているのは彼だけです。
この問題の根源は文書の不足です 。 結局のところ、システムのすべてのサービスが記述されていれば、アナリストなしで問題に対処することが可能になるでしょう。 devopsが忙しいスケジュールから数日を選択し、典型的な問題を解決するためのすべてのサーバー、サービス、および指示を説明した場合、不在の問題はそれなしで解決できます。 休暇中にビーチでビールをすぐに仕上げて、問題を解決するためにWi-Fiを探す必要はありません。
サポートスタッフの能力と責任
大規模なプロジェクトでは、企業は開発者への給与を浪費しません。 高価な仲買人や同様のプロジェクトの先輩を探しています。 サポートにより、状況はわずかに異なります。 彼らはあらゆる方法でこれらのコストを削減しようとしています。 企業は昨日の低コストのenikeyshikovを採用しており、大胆に戦いに出ています。 そのような戦略は、ゼレノグラードのある工場の名刺サイトに関しては可能です。
大規模なオンラインストアについて話している場合、1時間ごとにダウンタイムが発生するのは、管理者の月給よりも高くなります。 開始点として、年間売上高10億ルーブルを考えてください。 これは、 2018年のTOP-100評価からのオンラインストアの最小売上高です。 この金額を1年あたりの時間数で割ると、100,000ルーブルを超える純損失が得られます。 また、夜の時間をカウントしない場合は、安全に2倍にできます。
しかし、お金は主なものではありませんか？ （もちろん、主なことはありません）評判の低下はまだあります。 有名なオンラインストアが崩壊した1時間は、ソーシャルネットワークのレビューの波とテーマメディアの出版物の両方を引き起こす可能性があります。 「キッチンで何も買わないで、サイトは常にダウンしている」というスタイルのキッチンでの友人の会話は、測定にまったく役立ちません。
今責任があります。 私の練習では、オンサイトの管理者が、サイトにアクセスできないことを監視システムに通知するのに間に合わなかった場合がありました。 金曜日の夕方の心地よい夏に、モスクワにある有名なオンラインストアのサイトが静かに横たわりました。 土曜日の朝、このサイトの製品はサイトが開かない理由を理解していなかったため、Slackのサポートチャットと緊急アラートには沈黙があります。 そのような間違いは私たちに6桁の金額を要し、この任務官は働きました。
責任は、開発が難しいスキルです。 人はそれを持っているかいないかのどちらかです。 したがって、インタビューでは、人が責任を負うことに慣れているかどうかを間接的に示すさまざまな質問でその存在を特定しようとします。 両親がそう言ったために大学を選んだと答えたり、妻があまり収入がないと言って転職した場合、そのような人々と関わらない方が良いでしょう。
開発チームとのやり取り
ユーザーが操作中に製品で簡単な問題を経験した場合、サポートは自分で解決します。 問題の再現、ログの分析などを試みます。 しかし、バグが製品にポップアップ表示されたらどうしますか？ この場合、サポートが開発者のタスクを開始し、ここから楽しみが始まります。
開発者は常に過負荷です。 彼らは新しい機能を作成しています。 セールレッスンでバグを修正し、最も面白くないと言います。 次のスプリントを完了するための締め切りはついています。 そして、不快な人々がサポートから来て、「緊急にすべてを落とす、問題がある」と言います。 このようなタスクの優先度は最小限です。 特に問題が最も重大ではなく、サイトの主な機能が機能している場合、およびリリースマネージャーが目を膨らませて実行せず、「次のリリースまたは修正プログラムにこのタスクをもたらす緊急」と書かない場合。
通常または低優先度のタスクは、リリースからリリースへと進みます。 「タスクはいつ完了しますか？」という質問に対して、「申し訳ありませんが、現在多くのタスクがあります。チームリーダーまたはリリースマネージャーに尋ねてください。」というスタイルで回答を受け取ります。
製品の問題は、新しい機能を作成するよりも優先されます。 ユーザーが常にバグに遭遇する場合、悪いレビューはあなたを待たせません。 損傷した評判を回復することは困難です。
開発とサポート間の相互作用の問題は、DevOpsによって解決されます。 この略語は、開発用のテスト環境の作成を支援し、CI \ CDパイプラインを構築し、テストされたコードを実稼働環境ですばやく表示する特定の人物としてよく使用されます。 DevOpsは、プロセスのすべての参加者が互いに密接に対話し、ソフトウェア製品およびサービスを迅速に作成および更新するのに役立つ場合のソフトウェア開発へのアプローチです。 アナリスト、開発者、テスター、サポートを意味します。
このアプローチでのサポートと開発は、目標と目的の異なる部門ではありません。 開発は運用に関与し、その逆も同様です。 分散チームの有名なフレーズ「問題は私の側にありません」はチャットルームではあまり見られず、エンドユーザーは少し幸せになります。