みなさんこんにちは！
私の名前はロマンで、米国市場の大企業向けに高負荷のシステムを開発するためのコンサルティングサービスを提供する中規模企業（最大500人）で働いています。 クライアントの1つは、衣料品、履物、小間物、その他の消費財の販売で米国最大のオンラインストアのトップ5にある会社です。
当社に加えて、顧客企業へのコンサルティングサービスは、継続的に作業している別の12〜15の大規模ベンダーと、多数の小規模ベンダーを提供します。 これらの多くのベンダー（大小両方）が中国南西部の半島にアウトソーシングを行っています。 インドの伝統とメンタリティは私たちのものとは大きく異なり、西洋のものとはさらに大きく異なります。したがって、うらやましい規則性では、仕事中に多くの面白い状況があります。 ただし、この意見は、世界中に散在する他の文化のチームと協力することではありませんが、従業員が同じ言語を話す1つの会社の枠組みの中でも、この非常に誤ったコミュニケーションは簡単に発生する可能性がありますが、また、他の人とコミュニケーションをとる際にコンテキストを理解することの重要性についても。
少しのコンテキスト
私たちが取り組んでいるシステムは大きく、多くのコンポーネントがあります。 メインのWebサイトは、約80台のマシンを含むクラスター上で回転しています;小規模なシステムは5〜15台のサーバーのクラスターで動作します。 これはすべて、アプリケーション全体がピーク負荷の下で適切に動作するために必要です。 理論的には、いずれかのコンポーネントに障害が発生する可能性があるため、システムは、サブシステムの障害がシステム全体の誤動作につながらないように設計されており、それにより、365日24時間365日の主要な販売の中断につながらない顧客の利益の源泉。 彼らが言うように、プログラマのスキルは、エラーなしで機能するプログラムを書くことではなく、任意の数のエラーで機能するプログラムを書くことです。 私の記憶が正しければ、2015年のアプリケーションの可用性は99.98％の領域にあり、これはこのタイプのシステムにとっても非常に均一です。
契約に基づき、当社はシステム内の多くのコンポーネントのいわゆる所有権を持っています。 これは、ソフトウェアモジュールの開発/実装/保守/拡張を担当し、開発チーム以外は誰も許可なくこのモジュールのコードに忍び込むという事実にあります。 他のベンダーの地理的位置、それらの故障エネルギー、およびコーナーをカットしたいという通常の欲求を考えると、これはアイデアにはうまくいきません。実際には、これを達成するのは非常に困難です。
多くのモジュールの並行開発を行うために、インフラストラクチャは多くの環境問題を提供し、それぞれがウェブストアの完全コピーまたはその一部を実行します。 まあ、いくら。 本当に150-200個。 すべてのenvは、当社のDevOpsおよびNOC（ネットワークオペレーションセンター）チームによってサポートおよび開発されています。これらのチームの責任は、すべてのeneが機能し、必要なコンポーネントのバージョンをずらして配置し、何かが落ちた場合に、できればすぐに上げることです開発を損なうことなく。
生産におけるすべてのコンポーネントの可用性は顧客にとって重要であるため、当社は、チームが開発したモジュールの24時間サポートサービスも提供しています。 すべての開発者にそのようなサポートを提供することを義務付けることは特に正しくありません。そのため、L2 / L3サポートを担当する特別なチームSRE（サイト信頼性エンジニアリング）があります。 彼らは常に生産の技術的な問題を抱えていて、それを解決します。 通常、問題の95％に対する解決策は、シリーズの推奨事項を提示することです。「ここでは、クラスターから1つのインスタンスが残っているため、レイテンシが20％増加しています。 再起動して助けてください。」（L2）、または：「ああ、ここのコードにはカントがあります。今すぐ修正する方法を見てみましょう。 自分でできない場合は、開発者のメインチームを呼び出し、一緒に修正します」（L3）。
小売企業のホリデーシーズン（ブラックフライデー、プラスサイバーマンデー、プラス数日前後）は、1本のボトルで幸福と苦痛に終わります。 一方では、この1週間で、企業は年間利益の約15〜25％を稼ぐことができます。 一方、大量の衣服を割引価格で購入したいバイヤーが非常に多いと、ピーク負荷が発生し、一部のモジュールが負荷に耐えられなくなるリスクが生じます。 コンポーネントがスタック上のどこか遠くにあり、たとえば、すでに完了した注文のキャッシュである場合、これは注文処理チームにとって不便に作成されるだけです。 支払い取引を許可するサービスが失敗し、何らかの理由で買い手が小売業者にお金を提供できない場合、1日の収益額は数千万ブルジョアのお金で測定されるため、誰にも見えません。 要するに、ホリデーシーズン、またはピークとも呼ばれるピークは、非常に魅力的ですが、開発とサポートに関わるすべての人にとってストレスの多い時期です。
SREのピーク時には、チームは24時間年中無休で強化されたサポートを提供し、すべてのコンポーネントに遅れずについていきます。 これを行うために、チームは、これらの開発環境の1つで実稼働中のコンポーネントのカスタム監視を設定しました。 実際、彼らは（メインモニタリングに加えて）トリッキーなテストヘルスチェック-rekvestsを各システムに定期的に送信し、いくつかの統計を書き込み、突然コンポーネントの1つが愚かになって長時間応答するか、まったく応答しない小さなユーティリティを作成しました-すべての通信チャネルで勤務エンジニアにすぐに大声で叫ぶ。
この環境はQI58と呼ばれます。 正式には、envはSREチームに属します。つまり、理論的には、それら（および問題が発生した場合はDevOps / NOCチーム）以外は誰もそこにいるべきではありません。 ピークが始まる前に、念のために、チームはQI58ミッションクリティカルが重要なサービスをひねり、 すべてのチームに手紙を書きました。あなたはそれに触れる必要はありません、さもなければatatがあります。
エッセンス
どういうわけか、QI58も、コンポーネントの1つをテストできる唯一の通常構成された環境であることが起こりました。 そのため、通常、このenvはチームに影響を与え、テストに使用します。 過去数日間、開発チームはこの特定のコンポーネントのわずかな改善に取り組んできました。 ピークでこれを改善することは何の関係もありません、ただ拡張作業を計画しました。 そして今日、それをテストする必要がありました。 私たちは、SREチームに、あなたがQI58を今すぐテストすれば、あなたが反対していると言うと書いています。 はい、はい、監視を覚えています。 はい、慎重に行います。 30分ほどかかりますが、最後には登録を解除します。
そして、次のようなことが起こります：
- 私の開発チームの1人のファイターが、QI58でモジュールの手動デプロイメントを開始します（はい、このコンポーネントの自動デプロイメントは、さまざまな理由で機能しません）。 テストcurlを送信しようとすると、同じマシンからのリクエストでエラーが発生します： sed：440項目をstdoutに書き込めませんでした：deviceにスペースが残っていません 。 彼は、ディスク上の多数のログが原因で問題が発生する可能性が最も高いことを理解し、同じマシンで実行中の監視に影響を与える可能性があることを教えてくれました。
- 問題をSREチームに報告します。 マシンの場所に問題があると言いますが、それは監視にとって重要かもしれません。
- フィードバックはすぐに得られますが、これは非常に重要です。 また、NOCチーム向けにJIRAでチケットを用意することで、問題を探して解決できるようになりました。
- 戦闘機がチケットを開始します。 私はそれを見て、念のために、QI58はミッションクリティカルであり、重要なアプリケーションがその上で回転していることを思い出してください。 「NOCチーム、この環境は非常に重要であることに注意してください。」という精神で、チケットに対するコメントを書いています。 インスタンスの可用性に影響する可能性のあるアクションを実行している場合は、A、B、またはCに連絡してください。
- チケットは開発に使用され、10分後、次のコンテンツに関するコメントとともに「解決済み」ステータスになります。
この問題は、次の非標準のファイルとフォルダーを削除することで解決されます。
-gigaspace-monitoring.jar
-gigaspace-monitoring-libs /
-heartbeat.jar
〜150mbがリリースされました。 問題が再び発生する場合は、チケットを再度開いてください。
さて、その後、数時間の普遍的な楽しみ、マット、そして人生のその他の喜びが続きます。
学んだ教訓
概して、ひどいことは何も起こらなかったと言わなければなりません。 削除されたファイルはすぐに復元され、この間、監視対象システムのコンポーネントに重大な問題は発生せず、NOCエンジニアは一人も負傷しませんでした。 しかし、サーバー上で削除できるもののうち、最も重要なものが削除されたという事実は、もちろん叙事詩です:)
ちなみに、もう少し深く考えると、NOCの専門家は、愚かさのためではなく、QI58が重要な環境であることを忘れたためではなく、そもそも幸運で彼の前にいたとしても、彼がしたことをやった触るだけの価値のないすべてのファイルがキャッチされました。 問題の根源は、どの特定のプロセスが重要で、何に触れてはならないのかを明確に誰にも伝えていないことでした。 さらに、彼が行ったすべての作業は、専門的に、指示の枠内で行われました。
- 問題は迅速かつ効率的に解決されました。
- サーバーは再起動されず、削除されず、イメージから最初から作成されたなどもありません。 つまり 必要に応じて、可用性envaは影響を受けません。
- 環境が本来意図されたアプリケーションではない非標準コンポーネントが削除されました。
- 問題が発見された直後、NOCチームはすぐに作業を開始し、削除されたコンポーネントを復元しました。
したがって、行われるべき主要な結論：
- あなたに明らかなすべてが、あなたの文脈の外で他のことをしている別のチームの他の人に明らかであるとは限りません。 また、人々が複雑なシステムと大量の情報を扱う場合、特定の人の不完全なコンテキストが頻繁に発生します。 その人は、チームの全員が専門家であり、誰もが自分がしていることを理解して作業していると想定しますが、さまざまな人が異なるタスクのコンテキストを持っていることを懐かしく思います。
- ミッションクリティカルなものがある場合、誰もがそれがミッションクリティカルであることを理解するだけでなく、正確にそれが何であるか（OSプロセス、アプリケーション、ディスク上のファイルなど）を作成する必要があります。 これに加えて、アクセスが物理的または手続き的に制限されていることを確認することが重要です。 同時に、行き過ぎて、通常の仕事を妨げる官僚制度に巻き込まれるリスクが常にあるため、バランスが重要です。
- 場合によっては、問題を解決するための標準的なプロセスを開始する前に、人々とライブで話し、状況を伝え、全員が重要な詳細を理解していることを確認することが理にかなっています。
- 人的要因がすべての問題の根本原因です。 プログラミングに関するものではありません。 テクノロジーについてではありません。 ビジネスプロセスではありません。 それはすべて人に関するものです。
より多くのことを伝え、あなたの考えをはっきりとはっきりと言い、他の人の頭の中の絵は常にあなたのものとは異なることを覚えておいてください。
すべてに良い！