ドキュメントとナレッジベースの違い：ドキュメントには、このデバイスは摂氏+18度まで空気を冷却することが記載されており、ナレッジベースは、2つのセンサーがすぐに-51千度を示し、デバイスがサーバーの空気を熱くし始めたときにまれなバグがあることを示唆しています。
新しい小さなプロジェクトを開始すると、鉄片が床に置かれ、ドキュメントもニフィグもまったくなく、作業ができます。 その後、プロジェクトは数百人と数千の鉄片のサイズに成長し、どこに何があるのか、どのように行うのかなどを知る必要があります。
すべての通常の会計が必要です。 ドキュメントが必要です。 倉庫にどれだけ持っているのかわからない状況は必要ありません。 エンジニアが病気になったときに、残りの人が自宅で彼を呼び出して、1年前にサーバーをどのように構成したかを尋ねるという話は必要ありません。 誰かが10台のサーバーを上げるように言ったのに、2人の異なる人が別のやり方でそれをしたときの話は必要ありません。
しかし、私たちはシンプルなものから始めました。 質問は次のとおりです。サーバーファームウェアを更新するのは誰ですか？ 結果の責任者は誰ですか？ これはどのように行われますか？ 誰に警告する必要がありますか？ ロールバック計画の書き方とサーバーがクラッシュした場合の対処方法 少なくとも誰かが必要な電話を前もって書き留めていましたか？
一般的に、最初の熊手はあなたを地獄に殺すか、すべてを正しくするように教えます。 2番目は、レーキなしで発生しました。 レーキはほとんどありません。 すでに混乱している場合、私たちの経験は役に立つかもしれません。
鉄の会計
一番最初の簡単なことは、鉄がどこにあり、何が鉄かを考えることです。 これは、変更の処理、在庫管理、適切な会計処理に必要です。 たとえば、サーバーのメモリバーが燃え尽きました-ベンダーとインシデントを開始して変更する必要があります。 ベンダーは、すぐにFRU番号のバーを尋ねます。 バーの番号は鉄片自体に記載されており、IMMで番号を確認することもできます（ただし、機能する場合のみ）。 つまり、経理がない場合、エンジニアは機械室に行き、サーバーの電源を切り、このバーを取り出します（つまり、彼はFRUを知らないがDIMMを知っているため）、目を細めて、その数を言います。
ブラケット自体からすべての数字をスキャンしてサーバーを起動するか、サーバーを起動した後、ブラケットのデータをリモートで読み取り（ワーカーをリモートで表示できます）、不正なメモリの場所とその番号を正確に把握するのが正しいでしょう。
まあ、一般に、それがどのサーバーにあるか、保証の期限がいつ切れるか、どのプロジェクトで使用されるか、どのような構成などを理解することは素晴らしいことです。 100を超えるサーバーがある場合、常に更新されるマップなしでインフラストラクチャを管理することはすでに困難です。 私はこれを、経験のあるオペレーターなど、メモリ内で何をどこで知っているかなど、独自の知識を持つキャリアに任せたくありません。
また、記述されたサービスリソースモデルを用意し、何らかの種類のスペアパーツを用意し、インシデントの場合の内容を理解する必要があります。 新しいクライアントの場合、GIS PDで閉鎖されている同じ部分で、どの機器とライセンスがいくつあるか、どのリソースを接続できるかを十分に理解する必要があります。
ここでは、各サーバーでこのようなカードを使用して開始しました。
ご覧のとおり、ここではすべてのシリアル番号が考慮され、鉄の技術的特性が書き直され、特定の鉄についてオペレータからのコメントがあるかもしれません。 カードには、サポートが開始された時期とサポートが終了する時期も示されます。つまり、これに関するレポートを設定できます。これは費用の計画に役立ちます。
そして、カードはそれがすべて立っている場所と内部に詰まっているものを示しています。 この階層を見ることができます：
カードはこのリストに表示されます：
サーバーから始めてから、スイッチ、トランシーバーに進み、SCS要素の作成を開始しました-どのくらい、どこに、どのように接続するか。 すべてのサーバーについて説明します。任意のサーバーを開いて、その場所、データセンター、部屋、ラック、ユニット、スタック、接続方法を確認できます。 固定資産を使用して会計処理を行いました。サーバーはユニットとして考慮され、どのカードとネットワークドライブがインストールされているかがわかりました。 ディスクは一般的に同じで、シリアル番号が異なり、以前はどこが不明でしたか。 そして今、誰もが彼が配信される契約に縛られています。 実用的な利便性は、簿記では大量の機器が1つの固定資産に含まれることであり、私たちの場合、それは異なる部屋にあるラックに、または一般的なスペアパーツにさえ分配されます。 これで、会計およびクライアントの要求（在庫）の固定資産のすべての要素をすばやく見つけることができます。
ディスクカードの例、私たちはそれについてすべてを知っています
今すぐ処理
鉄が魂を温めているとき、それをさらに維持するために、プロセスを処方し始めなければなりません。 たとえば、銀行がクラウドに入り、その下に容量を追加する必要があります。 追加するもの、追加する場所、構成する方法、ネットワークを編成する方法を決定するために、アーキテクチャと説明を含む問題ステートメントが必要です。
私たちはこれをメールで議論し、タスクはタスクトラッカーで説明されていました。そして、全員が同意すると、操作が実行されました。
現在、2つのタイプのプロセスがあります。 変更が標準的な場合、「そこにポートを割り当てる」などのプロセスのすべての個別の部分（作業計画、返品計画、テスト計画、請負業者が定義されているかどうかなど）がすでに記述されており、それぞれがカレンダーに入れることができますServiceNowの変更。 プロセスは標準であるため、承認は必要なく、責任者がすぐに任命され、期限が設定され、これはすべて特定の実行者に当てはまります。 変更ごとにSLAがあり、申請者は自分のタスクを完了するための時間枠を理解しています。
例はポート割り当てです。 ポートをどこにでも割り当てることはできません。 最初の-たとえば、それぞれが48個のポートを持つ100個のスイッチがあります。 ポートは100 * 48ですが、これはいずれも区別できるという意味ではありません。 スイッチは、異なるデータセンターの部屋にあります。 どのポートを割り当てることができ、どのポートを割り当てることができないかを理解する必要があります。 標準変更計画によれば、エンジニアは、どこにどのポートを割り当てるかを知っており、以前に予約したポートを割り当てません。 2つ目-ポートはそれぞれ何かと対話する必要があり、異なる設定（セキュリティ、速度、帯域幅制限、QOS設定など）を適用する必要があります。これはすべてリクエストで説明されるか、変更計画で示されます。 第三-割り当てられている量、予約されている量を知っています。これはその後の設計に非常に役立ちます。
変更が非標準の場合、登録後の変更は変更マネージャーに送られます。 変更を実装するためのアーキテクチャ、作業計画、リスクが評価され、ロールバック計画が決定され、ダウンタイムが決定され、誰に通知されるべきか、作業の責任者があり、その後、すべてが承認のために送信される設計があります...一般的に、スクリプトシーケンスはすべてで書かれています最後の段落から分岐します。 これを書いた人は、リスクを説明し（彼が見ている）、各ケースのロールバック計画を準備します。 次に、プロセスを通じて、変更は変更委員会に送られます。 KABメンバーは、責任範囲に対して事前に定義されています。 次に、各参加者は変更計画とロールバック計画を見て、同意するかどうかを決めます。 必要に応じて-改訂。 必要に応じて-ウィンドウは一貫しています。 すべての承認後、実行者にタスクが設定されます。 しかし実際には、私たちはそれほど大きくないことが判明しました。 戦闘システムでは、KABはシステム内のエンティティとして「成長する」ために残されています。実際、これらはマネージャーや建築家です。
各変更には変更マネージャー（責任エグゼキューター）があり、変更を担当し、勤務中のシフトはすべての変更を監視し、監視を監視し、緊急の場合に顧客と通信します。 変更は、勤務中のシフトが操作性を確認した後にのみ閉じられ、変更マネージャーはテスト計画に従ってチェックし、CMDBとドキュメントを更新します。
事実は、結果をドキュメントに記録する必要があり、変更中に行われたすべてが資産ベースに反映される必要があるということです。 基本更新接続。 しかし、その後はすべてが閉じられます。
ここでそのようなプロセスを書き始めました。
プロセスとプロセスなしの違いは、プロセスがあるとドキュメントと官僚主義が増えることですが、何をすべきかは明確です。 以前は、誰でもやりたいと思っていました。 少数の人々がいる間、これはすべて、書かれていない標準に基づいていることは明らかです。 成長-それらを記述する必要があり、これなしでは多数のプロセスを管理することは不可能です。 責任の領域が現れました。 ケースごとに異なるSLAがあります。 計画を準備し、関心のあるすべての人に警告し、最後にすべてを調整して文書化する義務がありました。 その後、これはすべてITSMで自動化されました。
知識ベース
変更のフレームワーク内でのすべての作業は、構成アイテムに関連付けられています。 変更を登録することにより、標準化されたプロセスがあることがわかります：どのように作業を行うか、どの機器で、どのような人々の輪を定義するか-誰が同意するか、誰がそれを行うか、誰が何をするか、何かがうまくいかない場合など
私たちはすぐにリスク、そして将来的には仕事のコストを目にします。
しかし、これでは十分ではありません。
プロセスが説明していないものを説明する知識ベースが必要です。 たとえば、ファームウェアのまれなバグ。 または、ラックの最適な組み立て方法。 または接続方法。 エントリの例を次に示します。
これは主に、計画段階で建築家によって書かれた文書から行われます。 しかし、エンジニアや変更マネージャーは、作業を完了した後に何か新しいものを追加することがあります。
あなたは、鉄片についてのエントリを見て、彼らがそれに対して何をしたのか、そしてどのように前に知っているのか、全くわからない。 そして、それは3-4年でどんなスリルになるでしょう-ただ伝えることができません。
倉庫
ストーリーの次の部分は倉庫保管です。 テスト機器からのスペアパーツ、ツール、パッケージがあります。 これらはすべて、シフトシフト、運用サービス、およびアーキテクトが座っているオフィスに保管されていました。 データセンターに設置するためにエンジニアが集まると、オフィスに行って機器や消耗品（パッチコード、トランシーバーなど）を収集することがありました。 これはカオスにつながり、カオスは最初はクールです。
繰り返しになりますが、少し官僚主義です-そして、ここでスペアパーツについて説明しました（または、そのほとんどは、まだ「小さなものの箱」状態にあります）。 ソフトウェアにはアドレスストレージがありますが、これまで倉庫は組織的に実装する準備ができていません。各ピースには棚のスペースの形で座標があります。 エンジニアにインストールタスクが設定されると、「このスイッチをどこかに持って行き、これらのSFP、パッチコード」などをタスクに添付します。 こちらがラック、棚です。」
変更の役割
一部では、変更管理についてすでに説明しました。 この話のもう1つのことは、役割の分散があることです。
つまり、VMWareネットワークグループに属している場合は、VMWareゾーンでのみアプリケーションを送信できます。 各ロールには、実行できるプロセスのリストと、メンバーが設定できるタスクのリストがあります。 つまり、会社の組織構造全体をITSMに入力することもできます。
カオスと戦っているのは誰ですか？
私たちはチーム全体と戦っていますが、結果には私が責任を負います。 ところで、まだ多くの作業があります。 私の立場は「プログラムマネージャー」と呼ばれます。 これは、計画と共通の目標を達成するために実装する必要がある相互依存プロジェクトのリストを維持するタスクを持つプロジェクトマネージャーのようなものです。
それ以前は、小売店で物事を整理することに従事していました。特に、正しい会計のために大規模な小売店チェーンで自動会計と配達を行い、商品の受け取りと登録のコストを削減し、商品を棚に配達する時間を短縮しました。 IT企業では、変化のプロセスがはるかにスムーズに進んでいると言えます。誰もがその理由を理解しています。
新しいエンジニアがドキュメンテーションを上げ、その方法を上げ、チューナーのログ（誰かが魂の優しさで子孫を世話したものだけでなく）を読み、同僚からストーリーを収集できないことが明らかになったとき、どこに行くのかは明らかです。
最初は何もなかったので、いくつかの側面から作業を開始しました。 完全な結果はまだ達成されていませんが、6か月で、鉄、プロセス、および変更の作業についてより理解しやすくなりました。 クラウドは進化しており、これがその論理的なステップです。 これをすぐに行う必要はありませんでしたが、今がその時です。
先日、私たちは新しい倉庫をテスト運用に導入し、他のベクターの混乱と戦い続けています。 フェンスの前で作業しますが、結果は誰でも見ることができます。 おもしろい場合は、いくつかの小売りの話をすることができます-同じプロジェクトは、エンドユーザーや他の部門の長が積極的に抵抗しているという事実によって複雑になっています。 さて、プラス-あなたは皆に教える必要があり、多くの人にとって-「私たちは普通に働いた、触れないで」と考えて勝利する
このテキストは、Technoserv CloudオートメーションのプロジェクトマネージャーであるBoris Kosolapovによって作成されました。