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


9

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

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

本やウェブサイトに要約された、これらのアンチパターンの明確に表現されたライブラリがあることを望んでいました。多くの組織がトライアルバイファイア方式で学んでいることはほぼ間違いありません。そうでない場合は、始めましょう。


それでは、これはコミュニティWikiであるべきではありませんか?
ジョー

あなたが望むように....
ojblass 2009年

この質問は、現在の話題性ルールでは話題外です。
HopelessN00b 2015年

回答:


7

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

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


4

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

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

B.構成管理なし、統一なし-あちこちで変更があるだけで、ここでいくつか調整したと思います...

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

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

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

D. cfgに冗長性がない-XXが死ぬとどうなるか

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

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


それにアーメン。特にBとCです。Dはオプションですが、コストとメリットの問題であるため、常に冗長性を持つことはできません。
司令官キーン

Bを解決するためにPuppetを使い始めましたが、私はそれを十分にお勧めすることはできません。完了したら、ほぼすべてのサーバーを1時間以内に再構築できる状態になっているはずです。Cがない場合は、事実上盲目です。アラートがない場合、何が機能していないのかわからず、グラフ化しないと、将来何が起きるか、何が起こっているかを知ることができません。
David Pashley

4

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

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


あなたの2番目のポイントはとても真実です。そして通常それは技術的な制御を超えています。経営陣は技術者に退屈な日々の仕事をしてもらいたいと思っており、第三者がやって来て解釈の実装作業を行っています。その場合、組織内の誰もt =外部者がインストールしたものは何でもサポートできません。その後、技術者たちは、栄光のヘルプデスク担当者になったため、去っていきます。マネージャーは彼らと一緒に暮らすことはできません。:/
Jason Tan

2

1)見込みがあり、不足している(つまり、ユーザーの期待を現実的に保つ)

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

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


私は何も約束しようとしないことを習慣にしています:)
David Pashley

何も約束しないと、ユーザーも怒ってしまいます。何を約束するか、状況が変わった場合にどのようにして期待を再設定するかを、非常に貴重な方法で学びます。
Chris S

0

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

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


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

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

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

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

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

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

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

  • どこにでもテストファイルのコピー。ビジネスシステムまたはウェブサイトを実行するフォルダを開き、「website-new /、website-current /、website-copy /、website-testing /、website-test-dave /、website-use-」を表示したくない場合this-one /、website-from-feb /など)。開発、本番、テストが存在する必要があり、関係するすべての部門(IT、開発、プロジェクト管理など)が何をどこに置き、どのように変更するかについて合意する必要があります。構成ファイルにも使用できます。

  • 承認を変更する-最初に口頭で話し合ったとしても、誰も知らないうちに重要なものの動作を変更しないでください。状況に応じて「重要」な対象を決定するのはあなた次第です。

  • 束縛されたソリューションは長期にわたって残されました。緊急の問題に対処できるように、このサーバーに古い電話線を使ってすぐにパッチを当てたと思います。きちんとやり直す時間がないと思います。時間を作る。

  • 会社の他のメンバーとの貧弱な関係。ITは、会社全体が業務を遂行するのに役立つサービスです。巨大なファイルが必要な場合は、それを実現します。ハードウェアを購入するために経営者の承認が必要な場合は、入手してください。取得できない場合は、管理者が他の支出を優先しているため、巨大なファイルをすばやく移動できないことを明確に伝えます。法的な理由でアーカイブが必要だが予算がない場合は、できるだけアーカイブをシステムに適合させる必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.