Clever Geek Handbook

システム管理におけるブラックボックスとホワイトボックス

画像



私は、システム管理に対する正反対の2つのアプローチについて、仲間のシステム管理者だけでなく、彼らを仕事に連れて行く人々にも注目したいと思います。 これらのアプローチの違いを理解することで、双方の相互の不満を大幅に減らすことができるように思えます。



これは新しいことではないように思えますが、このトピックに関連するほぼ15年の間に、この2つのアプローチの違いを理解するための誤解や不本意に関連する問題、誤解、さらには対立を何度も目撃しました。 。 あなたがシステム管理者であり、あなたが仕事で安心していない場合、またはあなたがシステム管理者を雇うマネージャーである場合-おそらくこの記事はあなたのためだけのものです。



違いをもう少し視覚的にするために、意図的に少し誇張します。



ブラックボックス管理


ブラックボックスの管理（ボタンと電球を備えた黒く不透明な密閉ボックスのアナロジー）により、特定のシステムが存在し、その操作に関する指示、いくつかのトリック、質問と回答がGoogleにある状況を理解しています。 しかし、システムがどのように機能するかについての情報はありません。その中に何があるのか​​、それがどのように機能するのか、何が何の中にあるのか、どのように相互作用するのかは知りません はい、これは重要ではありません。通常の条件下で動作する場合、使用方法と期待されることを知っているだけです。 必要な結果につながる一連のコマンド/アクションが事前に説明されており、システムがこれをどのように行うかは関係なく、単に「順序付け」て結果を取得します。 または、前もって比fig的に説明されている場合（または入力によって、つまり経験によって発見された場合）、希望の電球の組み合わせを点灯するには、どのボタンを押す必要があります。



したがって、この場合の管理は、まず、システムが合意どおりに動作する標準動作条件をサポートし、次に顧客/ユーザーの要求に応じて「必要なボタンを押す」ことになります。 これは、どのボタンがどのランプを点灯させるかというよく知られた知識に従って厳密に行われます。バリエーションは歓迎されないだけでなく、禁忌です。別の方法が予期しない副作用を与え、システムを通常モードからドキュメントに記載されていない状態にすることができるためです状況を修正するために行うことは不明です。



何かがうまくいかず、システムが正常に機能しなくなった場合は、最初に行います-動作状態の問題点を検索します。これは、動作時と復帰方法、「すべてのライトをオフにする」方法とは異なります初期状態で。 これが役に立たない場合は、専門家から「秘密のボタンの組み合わせ」をグーグルで検索し、大切な光が点灯するか、システムが既知の状態に戻るまで、記載されている状況に類似する降順ですべて試してください。 これが役に立たない場合-行き止まり。 バックアップにロールバックするか、システムにサポートがある場合はサポートに連絡するか、システムを交換（再インストール）します。



このアプローチが唯一可能なシステムがある特定の数のシステムがあることに注意する価値があります。 たとえば、システムデバイスがメーカーの企業秘密であり、デバイスの調査の可能性が契約上の義務と社内ルールによって厳しく制限されている場合。 または、複雑な内部関係を持つ巨大で複雑なシステムの場合、そのさまざまなコンポーネントのサポートは、情報へのアクセス権を持たず、責任範囲外で何もする権利を持たないさまざまな部門によって実行されます。 さらに、このアプローチが単に適切な場合が多くあります。 たとえば、Winduは多くの場合、腸の破損を把握するよりも簡単に再インストールできます。



ホワイトボックス


したがって、 ホワイトボックスは、ボックスが透明なときです。 システムがどのように機能するかを見る（そして理解する）機会があります。 この状況では、命令は二次的なものであり、システムの使用方法と配置方法を理解できますが、これに限定されません。 システムがどのように機能し、その結果、ドキュメントに記載されていない条件を含むさまざまな条件下でシステムがどのように動作するかについて理解しています。



システムデバイスの調査にしばらく時間を費やした後、このシーケンスでボタンを押す必要がある理由と、そのような条件でシステムを操作する必要がある理由が理解できます。 望ましい副作用を事前に予測できるため、現在のタスクに最も効果的な方法を選択できるため、同じアクションをさまざまな方法で実行できます。 何かがうまくいかなかった場合-何がどのように壊れたのか、どのギアが詰まったのかがわかります。 システムを意識的に元の状態に戻すか、システムを正常に動作させない要因のみを変更することができます。 つまり、利用可能なドキュメント/経験からではなく、システムの内部状態とニーズから移行することです。



この状況では、問題を解決する可能性が何度も高まり、「行き止まり」がはるかに長く、より少ない頻度で達成され、システムをより完全かつ柔軟に、より効率的に運用できます。 しかし、このアプローチでは、はるかに長く複雑な情報をマスターし、消化し、一桁以上の情報を頭の中に保持する必要があります。



このアプローチも利用可能な唯一の方法です。 たとえば、システムが、絶えず開発、変更、補足を行っている会社の内部開発である場合。 したがって、誰も彼女に何を期待するのか分からず、多くの場合、ドキュメントが欠落しています。 この場合、システムがどのように機能するかを理解し、「ギアを掘り下げる」方法を知らない限り、合理的な時間内に単に解決できない状況が定期的に発生します。



問題の本質


私の個人的な経験から言えば、ほとんどのシステム管理者は、これらの2つのアプローチのいずれかでより快適に（そしてより効率的に）感じていると言えます。アプローチ。



両方のオプションについて、実際の（わずかに単純化されているため、重要ではないが時間のかかる詳細に時間を無駄にしないように）の例で検討します。



特定のサイトは、8GBのメモリを搭載した2つの8コアマシンで実行されます。 Apache2 + PHP + MySQL + memcache。 ピーク時に、システムは定期的にひどく減速し始め、サイト自体は10〜30秒の遅延で応答するか、まったく応答しませんでした。



まず、ブラックボックスアプローチに従って問題を検討しました。


両方のサーバーで、topコマンドは空きメモリがほとんどなく、負荷平均が約20であり、スワップがアクティブに使用され、システムがiowaitからクロールしないことを示しました。 Apacheを再起動すると、すべてが通常の状態に戻りました。 その後、1時間に1回cronにApacheの再起動を挿入し、さらに6か月間、問題を忘れました...



正確に何が起こったのか、なぜこれが起こったのか-残りの不明点、実際の問題は「サイトが遅くなり、開かない」、問題は解決され、サイトはもはや遅くなりません。 診断-3分、解決策-さらに5分。 つまり、問題が解決したのは10分未満であり、問​​題が発生した理由についてはほとんど何もわかりません。 これが長い間役立つだろうし、これが一般的な解決策であるという確実性はありませんが、（！） 10分で、実際にサイトはさらに約6か月間問題なく動作します。



6か月後、Apacheの1時間ごとの再起動にもかかわらず、問題が再び現れ始めました。 彼らは再起動間隔を短縮し始め、サイトへの接続が時々単に終了し、ページが過負荷になることが判明したという苦情が現れ始めました。 つまり、問題のまさに解決策が新しい問題を生み出し始めました。



さらに、同じシステムがより詳細に検討され始めました。 白い箱のような。


プロセスの詳細は省略します。その結果、システムはほとんど顕微鏡で研究されたため、結論についてすぐに説明します。 判明した：



解決策は次のとおりでした（プロジェクトの詳細を考慮していますが、ここでは説明しません）。





その結果、ラッシュアワーでは、25〜30個の軽量Apacheが同時に動作し、mod_fpmを介して5〜10個の重い個々のphp、node.jsが少し移動し、マイクロリクエストで同時に2〜5個のApacheプロセスを占有します。 突然形成された場合、Nginxキューは負担をかけずに簡単に保持されますが、プロセッサはほとんど何も消費せず、プロキシのみを使用し、アーキテクチャのおかげで数百の同時セッションをサポートするため、まったく問題はありません。 さらに、nginxはApacheの応答をバッファリングし、それらをクライアント自体にゆっくりと提供します。これにより、apacheはリクエストをより速く取り除くことができます。



その結果、「ラッシュアワー」でのサーバーの平均負荷平均は約0.2〜0.5になります。 メモリ消費-すべてのプロセスで約2〜3 GB。 残りのメモリはキャッシュです。 スワップは使用されません。 現在、応答時間はラッシュアワーで変化せず、静寂時とほぼ同じになりました（サイトにクライアントが2〜3人しかない場合）。

負荷の問題を抱えることなくサイトがサービスを提供できるクライアントの数は、約10倍に増加しました（データベースの問題はすでに始まっています）。



つまり、問題は再び解決されますが、今回は大きなマージンを持ち、何を頼りにし、問題なく機能するかを明確に理解しています。 すべてが正当化され、思慮深く、バランスが取れています。 決定時間は2週間です...



まとめ


「証拠のキャプテン」という称号を獲得する危険を冒して、私はそのような「分離」の結果に進みます。



  1. システム管理者を選択する前に、会社でサービスを提供する必要があるシステムのタイプを検討する価値があります。 複雑な自家製の絶えず変化するシステムの場合のBlack-Box-Guruは、White-Box-Guruと同じくらい有用ではない可能性が高く、その作業に満足することはほとんどありません。 「中に入る」のが望ましくない、安定した、うまく機能するシステムの場合のホワイトボックスの達人は、場所をまったく見つけず、おそらく個人的に、個人的なプロジェクトと実験のすべての自由時間を使って、正式にのみ動作します。 さて、または、彼は常に「現在のようにではなく、ここですべてを正しくやり直そう」とします。
  2. システム管理者は、「自分自身を理解する」必要があります。このアプローチは心に近いものであり、この理解に基づいてジョブを選択する必要があります。
  3. Black-box-guruは、十分に文書化され、広く使用されている新しいシステムのサービスを迅速に実行できるように、問題を非常に迅速に解決します。 結果は安定しており、予測可能です。 彼は同じように予測可能な方法で問題を解決することを好みます（特に、チームで作業する場合は、これはしばしば大きなプラスになります）が、常に最適とは限りません。
  4. White-box-guruは、システムの調査にかなりの時間を費やしますが、それよりはるかに効果的なソリューションを生み出します。 より複雑な問題や、ブラックボックスの達人の「行き止まり」状態に到達した問題を解決することはできますが、それほど高速でもそれほどでもありません。 同時に、迅速な「消火」には実用的ではありません。Apacheをただちに再起動するのではなく、「ホットトラッキング」で何が起こっているかを考慮し、不健全な状態のシステムの状態を「まだ表示」します。
  5. 大企業は両方のタイプの管理者とチームなしで行うことはできません。一部の人はシステムを少なくとも何らかの形で機能させる、つまり他の人は問題の根本を冷静に理解し、二度と起こらないことを確認します。 そして、これらの2番目のものは最初のものがうまくいくことを強制されるべきではなく、逆もまた同様です。
  6. 最も貴重な、しかし最も希少なショットは、両方のアプローチにうまく取り組むことができるものですが、彼らはまた、ある種のアプローチの一種を（より快適に）好んでいます。




従業員や仕事を選ぶとき、これらのいくつかの点を覚えておいてください。おそらく時間とお金と神経を節約できます。 これはおそらくこのトピックに関するすべてです。 それを読んだ人に感謝します。 :)


More articles:


All Articles