web-dev-qa-db-ja.com

システム管理の分野でよく知られているアンチパターンはありますか?

私は、ライフサイクルのある時点でほぼすべてのプロジェクトを悩ませているように見えるいくつかの一般的なパターンを知っています。

  1. 停止をとることができない
  2. アップグレードをロックアウトするサードパーティコンポーネント
  3. 不均一な環境
  4. 監視と警告の欠如
  5. 冗長性がありません
  6. 能力の欠如
  7. 不十分な変更管理
  8. 過度にリベラルまたはタイトなアクセスポリシー
  9. 組織の変更により、インフラストラクチャの所有権が不利にぼやけます

私は、本やWebサイトに要約されたこれらのアンチパターンの明確に表現されたライブラリがあることを望んでいました。多くの組織が火の方法による試験を通して学んでいることを私はほぼ確信しています。そうでない場合は、始めましょう。

9
ojblass

自動化可能なタスクを手動で実行するまで自動化したままにしておくと、タスクを手動で実行すると常に時間がかかるため、自動化できないほどの時間がかかります。

逆に、時期尚早の自動化。手動で行うのにN時間かかるワンショットタスクの自動化に3N時間を費やす必要はまったくありません(手作業で物事を処理するよりも自動化の方が楽しい場合でも)。

7
Vatine

最も致命的なパターンは、システム管理部門(またはIT全体)が会社の受動的な参加者になるときです。つまり、完全なITエコシステム全体のニーズではなく、ユーザーのニーズのみを考慮に入れて、すべての人が物事をどのように行うべきかについてすでに形成されたアイデアを持っているセルフサービスと見なされます。

2番目に大きなパターンは、システム管理部門が一連のボタンプッシャーに変わる場合です。つまり、すべてのソフトウェア/ツールはサードパーティによって購入または開発およびインストールされ、システム管理者は公式のトレーニングとマニュアルを取得してから、操作マニュアルのみに従います。マニュアルに明示的に記載されていないものはすべてベンダーにエスカレーションしてください。この状況は(ほとんどではないにしても一部の)システム管理者にとっては非常に快適かもしれませんが、システム全体が実際にどのように機能するかを誰も実際に知らないという事実がシステムを地面にもたらすときに起こるのを待っている災害です(コンポーネント間の微妙な相互作用を考えてくださいベンダー間の非難ゲーム)。

A.復元をテストしていません-バックアップは検証して問題ありませんが、復元する方法は?

どれくらいの時間がかかりますか、何がかかりますか?あなたはストレスの多い状況でそれをすることを知っている必要があります...

B.構成管理も均一性もありません-あちこちで変更するだけで、ここでいくつか調整したと思います...

すべての癖が書き留められておらず、ショップに同じ構成がない場合、よくできたサーバーを複製する方法を誰が知っていますか?構成アプリではなくデータの復元に成功した場合はどうなりますか?

C.監視なし-ボックスがどのように、何をしているのかわからない

これは2つあります。a)リソースが不足したり、奇妙な動作が発生する前に、アラームが時間内に反応するかどうかを監視する必要があります。b)容量(ディスク、CPU、RAM、ネットワークなど)を管理するために長期的な傾向を監視する必要があります。 ..)。

D.cfgに冗長性がない-XXが停止するとどうなるか

これは、システム管理者に何を求めているかを事前に計画することを意味します。

私にとって、これらは最も重要です。

4
slovon

1)期待を上回り、配信が不十分(つまり、ユーザーの期待を現実的に保つ)

2)必要になるまでバックアップを検証しません。

編集:私は2番目にファイル/データの復元を含めるつもりでした

2
J.Zimmerman
  • 重要な情報を1人の頭/受信トレイ/ドキュメントフォルダに保存します。ベンダーの連絡先の詳細、ライセンスキー、セットアップ手順などの重要な場合は、権限を持ち、アクセスする必要がある可能性のある部門のすべての人が、標準的な場所で利用できる必要があります。

  • 何かを知っている人にそれを文書化するように頼む。彼らは知識を持っているので良いように聞こえますが、重要な知識が何であるかを簡単に理解できないため、実際には悪いです。知識のある人に必要な情報を尋ね、それを行うときに文書化してもらうことで、誰かに新しい取引をさせるほうがよいでしょう。

  • 不明確なドキュメント。 IT部門全体が話し合うことができるので、誰でも日中の優先度の高い問題を修正できます。夜遅く、ほとんど一人で、システムがどのようにセットアップされているのか、またはドキュメントの内容と一致しないのかわからない場合に、優先度の高い問題を修正することも別の問題です。

  • パスワードをうまく追跡していません。したがって、すぐにアカウントが必要になり、ランダムなパスワードでアカウントを作成すると、18か月後もまだ使用されており、パスワードが変更された場合にどのサービスが機能しなくなるかは誰にもわかりません。

  • 「高すぎる」ため、主要システムのベンダーサポートを購入しない。

  • 不適切な優先順位。 IT担当者は、管理者によって指導される必要があります。どのプロジェクトが優先事項であるか、または緊急時にはどのシステムが最初に必要かについて合意する必要があります。 ITがビジネスシステムを修正しようとしている場合、管理者は電子メールを要求し、ユーザーは注文処理を要求しています。これは混乱のレシピです。

  • 不適切なソリューション-ITが「それを修正するには、ITシステムは以前のように機能している必要がある」という考え方にとらわれるのは非常に簡単ですが、「2を試す」という管理IT契約を結ぶ方が適切な場合があります。時間、それが修正されていない場合は、有望に見えても停止し、バックアップからの回復に移ります。」

  • どこにでもあるテストファイルのコピー。ビジネスシステムまたはWebサイトを実行するフォルダーを開いて、「website-new /、website-current /、website-copy /、website-testing /、website-test-dave /、website-use-」を参照する必要はありません。 this-one /、website-from-feb /など)開発、生産、テストが存在し、関係するすべての部門(IT、開発、プロジェクト管理など)がどこにあるべきかを理解し、どのように変更するかについて合意する必要があります。構成ファイルについても承認されます。

  • 承認を変更する-最初に口頭で話し合っただけの場合でも、他の人が知らないうちに重要なものの動作方法を変更しないでください。あなたの状況にとって「重要」なものを決めるのはあなた次第です。

  • 未解決のソリューションは長期的に維持されます。緊急の問題に対処できるように、このサーバーを古い電話線でそのネットワークにパッチを適用したことを知っています。正しくやり直す時間がないのはわかっています。時間を作ってください。

  • 会社の他の部分との関係が悪い。 ITは、会社の他のメンバーが仕事をするのを支援するサービスです。巨大なファイルが必要な場合は、それを実現してください。ハードウェアを購入するために管理者の承認が必要な場合は、それを入手してください。それが得られない場合は、管理者が他の支出を優先しているため、巨大なファイルを高速に移動できないことを明確に伝えてください。法的な理由でアーカイブが必要であるが予算がない場合は、アーカイブをシステムにできるだけ適合させる必要があります。

0

最終ログイン時間> 30日などのADアカウントの使用パターンを監視しない

(監査の理由でこれを行う必要がありますが、結果はかなり衝撃的です)

0
Garrett