同僚を混乱させるのは残念ですが、私の答えは「ありえない」です。 または、国内の広告が言ったように、「息子、これは素晴らしい」。 いいえ、本来、SLAを締結して実行するTier IVデータセンターとデータセンターがありますが、この記事ではそれらに焦点を合わせません（サービスコスト、しゃれを許さない、高額なお金のため）、しかし専用の物理および仮想サーバーとサービスのプロバイダーに焦点を当てますPixonicの私たちを含め、現在最も一般的な人間が使用しています。
私は、すでに表明されたアイデアを伝えるために、Pixonicと彼の両方で仕事をしなければならなかった特定の会社の名前を故意に与えません。とにかく、深刻な「ニュアンス」は誰にでも見られます。 誰かが議論するかもしれませんが、私の結論は、世界中のさまざまなレベルのデータセンターの技術サポートおよび管理と通信した8年以上の経験に基づいています。
ハリネズミは誇り高い鳥です。蹴るまで飛ぶことはありません
問題を次のように要約して誤解しないと信じています：サービスを使用するすべてのデータセンターの各直接契約者が、特定の条件付きナットを引き締めることに個人的に興味を持つまで、すべてがビジネスに悪影響を及ぼします。 しかし、状況を改善し、自分自身の生活をより簡単にするために、非常に簡単に。
たぶん私は今すぐに明らかなものを鳴らしますが、Pixonicの前では、どこかで実行されるのを見たことはありません。 ここではより良いことが判明しましたが、最初は体系的なアプローチが欠けていました。 その結果、私たちはそれを定式化し、実装し、実際にはるかに住みやすくなりました。
まず、簡単な質問から始めましょう。プロバイダーは、サービスの質に関する調査へのリンクを送信し、その通過に5分を費やすように要求します。 原則として、それらは「使い古された」ものであり、最も無害なものであり、その後はリクエストは単に無視されます。
お金を払って、あなた自身のビジネス、あなたの仕事があり、それを機能させるためにそれが必要だからです。 結局のところ、彼らのでたらめをする時間はありません！ おなじみですか？
秘密を教えましょう。完璧ではありませんが、試してみます。 そのため、彼らはこれらのポーリング、さまざまな利便性、監視、通知などのさまざまなインターフェースとAPIを実行します。 彼らがこのためのいくつかのツールを提供している場合、あなたのビジネスの利益のために試してみませんか？ WebユーザーインターフェイスとAPIを操作するためのドキュメントとナレッジベースを確認することから始めます。 プロファイル設定で連絡先を指定して、重要な情報（計画された作業に関する警告やブロックの脅威を伴う悪用など）が誰にも読めない共有ボックスに落ちないようにしますが、適切にタイムリーに応答できる特定の人に届きます。 たとえば、技術、ネットワーク、およびバルクのもの-管理者、および相互決済のすべての問題-会計および財務管理。
手紙を書く
さらに、各問題を理解してサポートに書き込むことを怠らないでください。 最初に、問題が解決しない場合は、すべてが記録されるように記述する必要があります。 これは、何かがあった場合にプロバイダーの側で次の担当者を突く場所があるだけでなく、必要に応じてチケットを同僚に見せるためにも役立ちます。 あなたのライターが十分なレベルで英語を知らない場合、それについて何かをしてください：同僚を惹きつけ、訓練し、翻訳者を雇ってください（Google翻訳は役に立ちません！）、最後に自分でやりましょう。
プロバイダーの担当者と書面でやり取りする場合は、次の点に注意してください。
- 原則として、さまざまなスキルレベルのエンジニアは、あらゆる瞬間に問題に取り組んでいますが、社内の規制によって制限されています。 多くの場合、チェンジャーはシフターブルと問題に関する情報を交換しません。同じことを何度も繰り返し、問題を徹底的に噛む準備をしてください。
- 通信に時間が記載されている場合は、UTCでタイムゾーンと時間の両方を常に確認してください。
- 問題の根本が明らかな場合は、手順を追って指示をコンマまで書き、マネージャーと通信して（それについては少し後で）不要な質問なしに暗黙的に実行されることを主張してください-原則として、上記の規制のため、エンジニアはあなたに義務付けられています同じサブネット上の異なるホストから1000以上の反復のMTR統計を収集して提供するなど、奇妙なことを尋ねます。
- 多くの場合、プロバイダーのテクニカルサポートはインシデントの調査によって持ち去られます。これには数週間かかる場合があります。 この場合、急進的な対策を求めることをnotしないでください。サーバーの物理的な交換または別のラック/ PDU /スイッチへの転送。
- チケットを編集するときに問題の重要度を設定できる場合は、少年とオオカミについての有名なたとえ話の状況にならないように正直に示してください。
- 意思決定者ではないプロバイダーとの「デブリーフィング」に関与する別の人がいる場合、彼は自分の立場を示す企業署名を使用しないでください-「よろしく、イメニャック」に限定してください-彼らは意思決定者として彼を知覚します問題にもっと積極的に取り組みます。
- 一般に、状況によっては、これが受け入れられる場合、スレッド内の正式な形式化されたHTMLメッセージの中に、署名なしでプレーンテキストで切り刻まれたフレーズを書く文字が表示される電子メール通信のモデルを構築すると役立つ場合があります-目標は同じです;
- すべての場合において、必要だと考えるときは、できるだけ早く略語と「ビジネスクリティカル」というフレーズをさまざまなバリエーションで使用します-彼らはそれを「愛します」上司がすでに問題を認識していることを技術サポートに示すチケット。
- これらの魔法のフレーズが3度目に機能しなかった場合は、明日、会話も支払いもせずに、それらから離れることを脅す-それは彼らにとってさらに爽快です。
そして、それが役に立たない場合は？
実際、実際には、主力製品であるPixonicのインフラストラクチャの一部のみが、プロバイダーXから実際に移動しました（悪魔に拷問されるように）。
原則として、プロジェクト全体で5〜10台のサーバーを使用していない場合は、プロバイダーはそれを維持することに非常に興味を持っています。 そして、彼らから彼らに尋ねる必要があります、いいえ、没収ではありません（ところで、私たちがビジネスクリティカルな事件で声を上げて話したすべてのプロバイダーのうち、すぐにどのように、どのくらいのお金を返すかを尋ねたのは1人だけでした）クラウドプロバイダーの機能不全、一時的なDNSの動作不能、トランクチャネルの問題による一時的なインターネットの不整合による経済的損失を計算するメカニズムがありませんか？ ここで最大値を要求する必要があります！ 最も簡単なことは、新しいサーバー/インスタンスの割引、無料レンタルまたは既存のサーバーの拡張、テクニカルサポートの品質レベルの改善などです。 しかし、別のマネージャーを必要とするのが最善です。マネージャーは-はい、はい-あなたのビジネスに対する関心を高めるために彼のチームを個人的に動機づけるでしょう
そのようなマネージャーとのコミュニケーションには、次のようなニュアンスもあります。
- 時には状況が非常に悪化するので、私はチケットに厳選したロシアのわいせつを書きたい。 そもそも英語で書かれていますが、それは邪悪ですが、本質的に抑制され、拡大され、問題自体だけでなく、プロバイダーの技術サポートとエンジニアの率直な愚かさの中でのコミュニケーションの妨害-このような問題は確かにマネージャーにエスカレートします。 、または書面ですべての問題を解決することを約束して電話に申し出ます。 状況を冷静に評価し、意思決定を行う技術者に直接連絡できる場合は、マネージャーの時間を無駄にしないでください-条件付きで、3番目の技術サポートラインの責任者;
- 危機的な状況では、電話をかけることは何かを解決するのに本当に役立つ場合にのみ有効です。 人生からの悪い例：どういうわけか彼らは異なる側面からの3人のマネージャーと1人のインド人エンジニアからconfコールを収集しました。
- それにもかかわらず、可能であれば、電話で話したり、直接会ったり、直接会うことは常に有用です。個人的な連絡先は、あなたのビジネスへの関心を高める可能性を高め、その結果、あらゆる種類の「アメニティ」の排他的な割引、facapsの補償のための特別な条件、回避不便な規制など。
30時間の痛み。 すぐに
顧客からの苦情の後の並行宇宙のどこか
根拠がないように、私はピクソニック時代に練習からいくつかの例を挙げます。 問題の規模を大まかに理解するために、明確にする価値があります。惑星の6つの地域に存在ポイントがあり、さまざまな成功度の異なるプロバイダーによって提供され、同様の問題が定期的にどこでも発生します。 さあ、行こう！
部屋全体をオフにしたら！ 明確化した後、プロバイダーは以前にこの部屋のサーバーの割引を提供していたことが判明しましたが、マネージャーはこの情報を特定のデータベースに入力するのを忘れていました。 プロバイダーの開発者の1人がデータベースからの情報に基づいて定期的に機器を通過し、「債務者」を切断し、それを修正する壊れたスクリプトを見つけるまで、サーバーは数か月間このように機能しました。
さまざまなプロバイダーでこのような自動化に複数回遭遇しました。 定期的に自発的にシャットダウンする2つのサーバーをセットアップしたら、 最初の疑惑-自動化-は真実であることが判明し、オフになりました。 しかし、1つのサーバーが定期的にクラッシュし続けました。 エンジニアは時間をかけて、可能なすべてをチェックしました。 彼らはそれを別のラックに移動し、それをオンにすることを忘れましたが、何も助けませんでした。 最後に、サーバーを変更する必要がありました。
これはオフィス管理者（「クリーナー」）の問題に似ていますが、評判の良いデータセンターでも発生します。同じラック内の複数のサーバーとの突然の通信がすべてなくなりました。エンジニアがインシデントを調査すると、コネクタがポートから「誤って」ポップアップしたことがわかります。 また、コネクタが単に破損していると言うことも起こります。 彼らがどのように事件に遅れずについていたかは理解できない。
ループの接続不良により、ハードドライブが奇妙な動作をするケーブルが存在する場合がありました。 青い目の技術サポートは、「彼らはそれをよりよく突き出した-うまくいった」と答えた。
プロバイダーのエンジニアは、作業するサーバーを混乱させることがあります。 また、パフォーマーとそのマネージャーがタスクで混乱し、まったく予期しないことをすることもよくあります。 切断についてのジョークのように：「私は左に言った。 私は手を言いました。」
どういうわけか、ある地域では50以上の「戦闘」サーバーのハードウェアを更新する必要がありました。 このアクティビティが生産に最小限の影響を与えるように、5個が更新されました。 そのため、各バッチで、1台の障害のあるサーバーに出くわす必要があります。 問題のある電源、破損したディスク、またはマザーボードの焼損。 その結果、更新にかかる時間が倍になりました。
更新についても、オペレーティングシステムについて。 プロバイダーは、OSの再インストールなど、サーバーを操作するためのWebインターフェイスとAPIを提供します。 私たちのケースでは、更新が必要なサーバーの80％で、これらのツールが機能しなかったことが判明しました！ プロバイダーの開発者はそれを理解することを約束し、当時のテクニカルサポートはOSを手動で再インストールすることを提案しました。 Windowsの最初の再インストールには、エンジニアから2日かかりました。
インターフェースに関するもう1つのこと-「粘着性のある」インターフェースが実際には動作しない場合がありますが、テクニカルサポートは別の言い方をします。 複雑な感情は、有名なプロバイダーのエンジニアが手動で何かを選んだときの状況によって引き起こされます。
一度、同じクールプロバイダーのエンジニアから、「戦闘」仮想マシンをダウングレードして、いくつかのメトリックの監視が正しく機能しない理由を理解するように依頼されました。 これは、監視の問題に誤って気づき、仮想マシンの1つのリソースを削減する計画を立てたときに問題が発生したためです。
そして最後に、おそらく最も「楽しい」物語。 長い間、地域の仮想マシンの一部で「フローティング」ネットワークの問題が発生していました。異なる時間帯の1日の異なる時間に、クライアントTCPセッションが切断されていました。 プロバイダーは、これは不可能だからではないと強く主張し、問題の予測不可能性と、マシン自体ですべてが正常であったという事実のために、証拠を提供できませんでした。 その結果、これらの仮想マシンは同じ物理ハイパーバイザーにある可能性が最も高いという仮定に至りました。 彼らは、ホスト自体をチェックするという申し出でプロバイダーに仮定を引き渡し、その後魅力的なことが起こりました。 最初は、マシンが異なるホスト上にあると言われましたが、いまだに1つのホスト上にあり、エンジニアは問題を確認し、問題が解決したことを積極的に報告し、その後、すべての仮想マシンがすぐにダウンしました。 結局のところ、ホストは単に負荷に対処できず、マシンが「大量のトラフィックを生成した」ため、これらの単純な男たちは「他の顧客に影響を与えないように」愚かにそれらをオフにすることにしました。
与えられた例が十分でない場合は、コメントで質問してください-私はいくつかのより有益な物語を思い出してみます。 より良いあなたのものを共有します。
おわりに
繰り返しますが、この記事で表明されたアドバイスは、現実のデータセンターに関する期待の相違によって生じる問題を最小限に抑え、ビジネスタスクに焦点を当てるために従うのに十分なほど単純です。 しかし、これらの問題は何らかの形で現れます。 Pixonicのように、アプリケーションを最大限に保護するには、アプリケーションアーキテクチャのレベルでフォールトトレランスと柔軟なインフラストラクチャを構築します。 また、1000以上のMTRを収集するのではなく、プロバイダーの代表者とのコミュニケーションで訴えるものがあるように、監視を適切に設定してください 。