無視された利害関係者a.k.aシステム管理者

Question

しばらく前に、私がこれまで取り組んできたほとんどすべての顧客プロジェクトが、重要な利害関係者グループであるシステム管理者を無視していることに気付きました。

これらのサイレントヒーローは通常、プロジェクトの最後にのみ関与し、今後数年間はインストール、サポート、およびメンテナンスが必要な実行可能なブラックボックスが残ります。このブラックボックスで問題が発生するたびに、ブラックボックスまたは基盤となるプラットフォームによって利用可能になったランダムな情報とツールサポートを使用して解決する方法を見つける必要があります。 。

彼らが最初からプロジェクトの利害関係者として関与していた場合、潜在的な問題を予測し、プロジェクトチームにそれを知らせる機会があったでしょう。しかし、現実は異なります。開発者としての私は、システム管理者を追加の利害関係者として関与させたいと考えていますが、外部要因がこれを防ぐことができます。

このような状況では、私たちのサイレントヒーローをできる限り助けたいと思います。だから私の質問は：

システム管理者は、開発者が維持する必要があるシステムを開発するときに、開発者に何を望みますか？

システム管理者である場合は、かつて発生した困難な問題と、それを簡単に解決するために開発者ができたことについて、戦争の話を聞かせてください。

Answer 1

これらを含む（ただし、これらに限定される可能性は低い）優先順位ではないさまざまなもの：

• 特権インストールを使用する必要はありません
• 特権インストールを使用するオプション
• 分散インストールのオプション（したがって、サーバーにインストールして他のマシンで使用できます）
• クリーンアンインストール
• 適切なアップグレードパターン
• インストール場所を選択するオプション
• 他のソフトウェアへの最小限の依存関係
• システム周辺のデータの最小限の分散（/ etc、/ usr / lib、/ var / adm、...にデータをダンプしないでください）
• 増え続けるログはありません
• サイレントインストール
• スクリプト化されたインストール
• オンラインドキュメント（マシン上およびインターネット上）
• おそらくマンページ
• 設定が簡単
• エンドユーザーがアクセスしやすい
• セキュリティリスクなし
• 特別なユーザーまたはグループはありません（または限られた数-特別なユーザーを1人まで、1つの特別なグループがターゲットですが、常に達成できるわけではありません）
• 「phone home」機能がないか、明示的に設定されている場合のみ（デフォルトではない）
• 問題がある場合の診断の良好なロギング
• 問題がある場合は、優れた技術サポートを利用できます
• インストール中にアクティベーションコードを取得する必要はありません
• インストール後にマシンを再起動する必要はありません
• 古いバージョンと新しいバージョンを並行して実行する機能

多くは、ソフトウェアが何であり、どのように使用されるかに依存します。 Windows、Linux、およびMacOS Xで動作するGUIプログラムの要件は、ネットワークデーモンの要件とは根本的に異なりますが、目標は依然として安定しており、信頼性が高く、管理が容易なソフトウェアでなければなりません。

社内で使用するために社内で作成したソフトウェアと、そのソフトウェアを開発する会社の外部の顧客が使用するために準備したソフトウェアには大きな違いがあることに注意してください。

Answer 2

必然的に問題が発生した場合は、システム管理者の言うことに注意し、彼を信じてください。最初の評価に合わない場合は、すぐに却下しないでください。

戦争の話：約6年前、私は小規模な製造会社のシステム管理者でしたが、彼らは機器の予防保守のスケジューリングを処理するソフトウェアを購入することにしました。その機能の1つは、電子メールからメンテナンスリクエストをインポートすることでしたが、このプロセス中にメールサーバーと通信する際にエラーが発生することがあり、開発者との電話中に確認するために最終的に呼び出されました。会話には複数の反復が含まれていました

  

開発者：誰も聞いたことがない   そんな話をして   メールサーバー。それは   ファイアウォールの問題。

     

私：ファイアウォールにログインしています。   パケットスニファーを実行し、見て   アプリのトラフィックは、   問題。ファイアウォールをうまく通過しています。

     

開発者：いいえ、いいえ-それは   ファイアウォールの問題。

（最終的に、問題はアプリがPOP3接続を開き、すべてのメールを読み、ユーザーがタスクをスケジュールするのを待ってから、POPコマンドを送信してすべてのリクエストが終了した後にメールを削除することであることが判明しましたユーザーがスケジューリングに15分以上かかった場合、POP接続がタイムアウトし、アプリが回復できなかったため、代わりに終了しました。その後、ユーザーはスケジューリングを繰り返す必要がありました。タイムアウトになるまで時間がかかります...）

Answer 3

次の組み合わせが考えられます：

1）容量のしきい値-＆gt;このソフトウェアを実行するのにどのマシンが必要で、この数値がいつ変更される可能性があるかを判断するためにどのメトリックを使用する必要がありますか。 2台から3台のデータベースサーバーに移行するか、10台から15台のWebサーバーに移行します。ハードウェアがどれほど堅実である必要があるか、そしてある部分が別の部分よりも重要であるかCPUはRAMよりも重要ですか？ハードドライブの構成とスペースはどうですか？

2）クックブックスタイルのトラブルシューティング-＆gt;何かがうまくいかない場合、これはコード、データ、またはネットワークエラーに簡単に分類できます。

3）環境の図-＆gt;このソフトウェアの開発、テスト、および実稼働インスタンスはどのように見えますか？現在実行中のこれらの環境と他の環境はありますか？

4）メンテナンス-＆gt;レポートに解析するログファイル、送信する毎週のエラーログ、またはソフトウェアに関連する何らかのハウスキーピングがありますか？サーバーを毎週再起動します。

5）セキュリティ-＆gt;作成および管理するアカウントと、システム上で誰がどのレベルの権限を持っているかを概説するセキュリティポリシーがあります。

これらが私の頭に浮かぶ主なものです。

Answer 4

システム管理者は通常、次のものが必要です。

• システムの操作への透明性。そのため、システム設定と、おそらくシステムの問題の履歴、およびシステムが正常に処理したもののリストを表示する何らかのGUI。
• 問題に対する明確な状況依存のエスカレーションパス。つまり、問題の種類ごとに修正に関するメモがあり、問題をすぐに修正できずエスカレーションが必要な場合に連絡できる人またはチームがいます。
• 予防的に、つまりエンドユーザーがシステムの問題を通知する前にエンドユーザーにシステムの問題を通知できるようにします。したがって、実行可能なシステムの問題については、何らかの即時アラートが発生します。
• アラートが殺到しないようにします。したがって、アラートが到着すると、同じ問題に関するアラートはもうありません。システムが再び動作可能になったときの別のメッセージ。
• 問題の詳細な調査のために、イベントログ（Windowsのような）を使用した詳細なログ記録。

Answer 5

システムが機能するので、子供が家に帰ることができます。

Answer 6

自宅の管理者の経験がどうでもいいなら、ソフトウェアに同梱されているよく文書化された依存関係。

Answer 7

まあ、戦時物語よりも恐ろしいことです。明白な理由もなく管理者ユーザーアカウントで実行する必要があるアプリケーションを維持することです。

アプリケーションにあるといいと思うランダムなもの：

• 意味のあるコマンドライン引数
• ある種のスクリプト機能（該当する場合）
• 長時間実行される操作のあらゆる種類の進行状況インジケーター
• エラーログ
• 一貫したUI

Answer 8

簡単なパッケージメンテナンス！

ソフトウェアのインストールとアップグレードは非常に簡単で、依存関係も同様です。多くの依存関係とサブ依存関係があり、各オペレーティングシステムのパッケージ管理方法の微妙な違いをマスターしたくない場合は、必要な依存関係すべてを巨大なtarballにバンドルしたパッケージバージョンを提供することをお勧めします。 。スクリプトを実行し、すべて/ usr / local / yourprojectにチャックし、startup / shutdown / restartスクリプトがどこにあるかを伝えます。

Answer 9

すべてのプロジェクトには、システムアーキテクチャとともに「容量計画」があります。システム管理者は、キャパシティプランニングプロセスおよびシステムアーキテクチャの最終レビューに関与する必要があります。これは、彼がシステムをよりよく理解し、展開とサポートの準備をするのに役立ちます。