回答:
アプリケーションには、おそらくアップまたはダウンよりも多くの状態があることに注意してください。状態図を描きます。ほとんどのアプリケーションには次のような状態があります。
各状態の間にシステムがクラッシュした場合にどうなるかを考えてください。sysadminは状態遷移をどのように監視および制御しますか？
「ユーザー」をSAと区別します。
「ユーザー」は、ソフトウェアの使用方法を知っている必要があります。ユーザーは、ソフトウェアのインストール方法などを気にしません。
SAはソフトウェアの使用方法を気にしませんが、ソフトウェアのインストール方法に関するいくつかの重要な詳細を知る必要があります。
それぞれの役割に関連する情報を含め、それらの役割ごとに個別にドキュメントを作成します。
私の願いの1つは、例外とエラーコードに適切なメッセージを含めることです。アプリケーションを開発していない人にとって、それJimmyNotAtHomeException: it's late!は何を意味するのか完全に不透明です。
しかし、このようなメッセージUnable to find jimmy - initial manual call_mother procedureは非常に役立ちます。
コミュニケーション、コミュニケーション、コミュニケーション。システム管理者と開発者の間のすべての問題は、ほとんどの場合、通信不足にまでさかのぼることができます。プロジェクトの前に、システム管理者（またはその代表者）と開発者が集まり、フレームワークについて話し合うと、SOOOOOOOOOO多くの問題を回避できます。アプリがアプリサーバー+ DBサーバー+インターフェースサーバーなどに分離されるので、開発中の1つのボックスで全員を開発して、製品が炎上するのを見るだけで、どれだけファウルが発生するかはわかりません。このトピックを取り上げてくれた名誉。
プロジェクトの早い段階で私たちに参加してください。機能仕様の段階で、本物の初期のように。
他の誰かがすべてのPCに手動でインストールする必要があると述べましたが、構成および構成の変更についても同じことが当てはまります。接続文字列のようなものをクライアント側に保存することを選択し、それらを定期的に更新する必要がある場合、おそらくあなたを殺したいと思うでしょう。
同じ理由で、適切に集中管理および構成できるテクノロジーを選択してください。使用する中央管理ツールとうまく統合できることを確認してください。
常に最小公分母を使用してテストしてください。これは、管理者ではない、最も原始的なOS、アプリケーションスイート、およびブラウザプラットフォームで一般的に使用されていることを意味します。私たちは、すべてのユーザーに必要なブラウザーのアップグレードが最後の瞬間に私たちに到着したことを嫌います。
物事がうまくいかないときに私たちを責めるためにジャンプしないでください。私の以前の仕事では、アプリが壊れるたびに、開発者はすぐに私たちに指を向けていました。「新しいパッチをインストールした、ブラウザをアップグレードしない、セキュリティが厳しすぎる」など。これは破壊的な雰囲気を生み出します。私たちは本当に同じ側にいて、あなたと一緒にそれを修正したいと思っていますが、そのような状況ではできません。
エリートにならないでください。
「私の時間を無駄にしないでください。あなたはただの犬のシステム管理者です。私はソフトウェアを書いて、あなたはそれをサービスしているだけです。
開発者が実際にこれらの言葉を一度言った（1）。メールで。大規模な配布グループにCCされました。その意味は明確でした。開発者として、彼はソフトウェアの世界全体の主人でありマスターでした。そして、私は彼が貴重な時間を無駄にするにはあまりにも些細な仕事に対処するために雇われた単なる日雇い労働者でした。もちろん、これはほぼ最悪の例ですが、ご存知のように、以前と以来、多くの開発者からそのコメントの強いエコーと弱いエコーが聞こえてきました（2）。
あなたは私よりも多くのお金を稼ぐかもしれません（しかし、それを仮定しないでください！）。しかし、ユーザーが依存するシステムを構築、運用、および保守するにはチームが必要です。最終的に私たちは皆それらに仕えます。
あなたの仕事とスキルは私の仕事とは違うと思います。あなたの能力を尊重します。私の質問があなたにとって初歩的で愚かに見える場合でも、あなたが答えてくれることを願っています。この礼儀を元気に戻します！
非常に多くの悪い（または単に気にしない）開発者がさまざまなフォーラムで発言し、考え、投稿しているので、私は狂ったパワートリップではありません。しかし、私の懸念はあなたのものとは異なり、私の質問や提案は私のエゴに役立っていません。実際、私の仕事は、アプリを最高の実行状態に保ち、すべてのユーザーに利用可能かつ応答性を維持することにより、見栄えを良くすることです。そのためには、ネットワークとシステムの残りの部分も最高の状態で実行する必要があります。
私はあなたが過去に愚かで、パワー狂った、そして/またはただ怠け者の管理者に出くわしたことを完全に知っています。私は一人にならないように、一人のように見えないようにしています。この可能性の余地を残し、それを見たときにそれを認めると、他の嫌いな人がまだ彼らのシステム管理者が嫌いな人であると発言している間に、あなたが必要なものを手に入れると確信しています。
（1）彼はまた、自分のプログラム（ソフトウェア要件を作成および管理するツール）をインストールして実行するにはドメイン管理者特権が必要であると主張していました。これは重大なセキュリティリスクでした。
（2）私はまた、必要なときに教えることができ、必要なときに学ぶことができる多くの素晴らしい開発者と仕事をしました。
システム管理者がやるべき仕事があることを尊重し、彼らに仕事をさせてください。多くの企業ではシステム管理者が無能であり、これは現実的ではありません。しかし、sys慢な開発者は、システム管理者が能力を証明した後でも、システムグループのアドバイスを無視するのを見てきました。
sysadminsと新しいシステムの設計について話し合います。多くの場合、貴重な洞察があります。開発者は、多くの場合、システム管理者との議論を検討し、初期要件を「時期尚早な最適化」として提供します。実際、開発グループの責任者は、それが時間の無駄だと言っているのを見ました。新しいデータベースサーバーの要件をsysadminとDBAで議論します。必要なストレージの量。
システム管理者とパフォーマンスの問題について話し合います。正直なところ、システムのパフォーマンスメトリックを適切に解釈できるのはsysadminだけです。開発者は、「free」の出力が10回説明された後でも、「free」によって報告される空きメモリが常に減少するため、Linuxは常にメモリをリークすると判断しました。
システム管理者と議論せずに結論を出さないでください。開発者は「データベースは常にディスクにバインドされている」（iostatが存在することさえ知らなかった）、「RAID 5はトランザクションワークロードの方が速い」（移動した1つのデータベースシステムの回想に基づいて）あるハードウェアプラットフォームから別のハードウェアプラットフォームへ-読み取り集中型のワークロードであったため、RAID5ソリューションではより多くの高速なドライブがより多くのコントローラーに分散していました。
システム管理者と議論せずに、システムの問題に対する解決策を設計しないでください。私は、開発者がソリューションを設計し、小さな実装支援を求めてくる1つの病理学的環境で働いていました。私以外のUnixグループのメンバー、Unixグループの責任者、および彼の上司は、開発者をインフラストラクチャ全体を機能させようとする同僚としてではなく、「顧客」として扱いたいと考えていました。顧客が常に正しいということは、彼らが何をしているのか、またはその理由を問わないことを意味します。正しい解決策を決定できるように、問題を説明することを主張するのは私だけでした。このような病理学的環境を作り出すような行動をしないでください。それは最終的な利益にはなりません-代わりに、システム管理者は防御的に行動し、誰もが苦しむでしょう。
あなたはもう学校にいません。これらは現実のシステムであり、理想的な方法で動作しません。たとえば、すべての遅延がゼロというわけではありません。システム管理者がクラスタ化ソリューションは政治的目的のみであり、システムの複雑さが増すと全体的な信頼性が低下することを警告する場合、真剣に考えてください。実際の障害モード用に設計する必要があります。たとえば、TCP経由で通信しているサーバーが失われた場合、接続はおそらくリセットされません。システム管理者は、実際の障害モードを理解しています。
システム管理者からの指示に耳を傾けるか、システム管理者が無能で解雇される必要があることを経営者に訴えます。システム管理者を無視しても意味がありません。
アプリケーションのデプロイ方法を検討してください。これをシステム管理者と議論することが理にかなっていることを理解してください。同一の100台のサーバーがあり、単一の構成ファイルのみに基づいて異なる場合は、これらの構成ファイルのマスターコピーを中央の場所に保存することを検討できます。アプリケーションの再デプロイが簡単な場合、誰もがどれほど良いかを実感してください。システムに問題がある場合は、1分以内にスペアに再展開するか、破損したシステムが修復されるのを待ってください。アプリケーションを再デプロイできる場合は、OSをより簡単かつ安全にアップグレードできます。将来これについて気にするかもしれません。
OSが原因であると思われる問題がある場合は、すぐにsysadminを呼び出してチェックアウトすることをお勧めします。しかし、大まかな調査で何も明らかにされなかった後は、問題を説明する義務があります。
「ゆっくり応答する」と「まったく応答しない」には違いがあることを理解してください。
開発対象のOS（en）に合わせて変更可能な予測可能な方法で、予測可能な方法で構成およびレイアウトします。これはすべてを意味します。たとえば、OpenLDAPにはログレベルを行う奇妙な方法があります。特定のIMAPサーバーには構成ファイルさえありませんが、オプションをコンパイルする必要があります。一部のパッケージは、特定のものを1つの特定のディレクトリパスに配置することを望んでいます。これにより、特定のオペレーティングシステムの規則が破られます。これらはすべて、私の通常の設定ではいぼとして際立っています。
それは一般的なルールですが、あなたが特別であると仮定しないでください。したがって、それが必要なソフトウェアに固有の豊富な正当な理由がない限り、プラットフォームでのソフトウェアパッケージの一般的な動作に関する一般的な規則を破ることに祝福されます。「これはそうあるべきだと強く思う」だけでは、みんなの通常の設定を破るには十分ではありません。ソフトウェアが実行しようとしている機能に関連する理由である必要があります。
アプリにサーバー間通信がある場合は、設計段階で少なくとも1人のシステム管理者を含めてください。また、他のサービス（SQL、SMTP、HTTPなど）への依存関係を明確に文書化してください。
ソフトウェアを数十または数百のシステムに自動化して展開できるようにしてください。組織がソフトウェアパッケージを必要とする場合、システム管理者はすべてのボックスに手動でパッケージをインストールする時間を持っていません。ファイルにライセンス情報が必要な場合、ファイルの提供方法を文書化することは大きなメリットになります。
アドビは歴史的に、作業するのが大変なインストーラーをいくつか持っています。それより高く目指してください！
運用のための設計。
ここの他のすべてを超えて...
私の経験では、最も大きな違いを生むのは、開発者が1日目から展開を検討するかどうかです。実稼働/顧客環境で新機能を考え始めるとすぐに、その中に展開する方法について考え始めます。環境、およびその実行方法。
彼らが開発プロセスに入ったら、手遅れではありませんが、視点をそこまで変えることができるようになるまでには時間がかかります。彼らは、コードベースをどれほど抽象的に見ているのか、それと対forcedせざるを得ないのです。彼らの考えでは、それは単なる「コンポーネント」です。特に興味深いのは、以前の（または古い！）バージョンのソフトウェアを実行して、既存の環境にどのように展開するかです。展開に関する議論は、新しい機能に対応するためのアーキテクチャの調整方法に大きな影響を与える可能性があります。
-ここに述べた他のすべて、SO上でこの記事を見に加えて：確かそれはサポート可能です作りますhttps://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support-ドキュメンテーション/