開発者に別の方法で何をしてもらいたいですか？
開発者として、私はほとんどの時間をコード、UI、データ構造などについて考えることに費やしていますが、（勇気を持って認めます）展開するときまで、システム管理者やDBAに対するアプリの影響を考慮する傾向はありません。アプリ。
まず、ごめんなさい。第二に、私とあなたが扱っている他の開発者が違うことをしたいと思いますか？生活を楽にし、問題を減らし、協力を促し、クラッシュ、パフォーマンスの問題、構成の悪夢を減らすものは何ですか？
- 0日目からセキュリティについて考えて組み込みます。
- ソースコード、ドキュメント、構成など、すべてにバージョン管理を使用します。
- ドキュメント、ドキュメント、ドキュメント。
- プラットフォームネイティブのパッケージを使用した、クリーンなインストールとアンインストール
- ライブラリおよび実行可能ファイルから構成データを分離する
- テストと移行のために異なるバージョンを並行して実行するためのサポート
- 堅牢で構成可能なロギング
- 軽量、正確、安全な監視
- アプリケーションのチェックポイントとバックアップ
- アプリケーションは、メモリ不足、ファイルシステムのフル、ネットワークのダウン、構成ファイルの欠落/破損、タイムスキューなどの問題にどのように対応しますか？
- 常に個別の開発、テスト、および実稼働環境を用意してください。すべての無料のVMソフトウェアで、言い訳はありません！
アプリケーションには、おそらくアップまたはダウンよりも多くの状態があることに注意してください。状態図を描きます。ほとんどのアプリケーションには、次のような状態があります。
- ダウン
- 初期化
- 回復
- up-but-not-accepting-work
- 待っている
- チェックポインティング
- 処理
- 仕上げ
- シャットダウン
- ダウン
各状態でシステムがクラッシュした場合にどうなるかを考えてください。 sysadminはどのように状態遷移を監視および制御しますか？
「ユーザー」とSAを区別します。
「ユーザー」は、ソフトウェアの使用方法を知っている必要があります。ユーザーは、ソフトウェアのインストール方法などを気にしません。
SAはソフトウェアの使用方法を気にしませんが、ソフトウェアのインストール方法に関するいくつかの重要な詳細を知る必要があります。
それぞれに関連する情報を含め、これらの役割ごとに個別にドキュメントを作成します。
私の願いの1つは、例外とエラーコードに適切なメッセージを含めることです。 JimmyNotAtHomeException: it's late!が何を意味するのか、アプリケーションを開発していない人には完全に不透明です。
ただし、Unable to find jimmy - initial manual call_mother procedureなどのメッセージは非常に役立ちます。
プロジェクトの早い段階で私たちを関与させてください。機能仕様の段階で、実際の初期のように。
他の誰かがすべてのPCに手動でインストールする必要があると述べましたが、同じことが構成と構成の変更にも当てはまります。接続文字列のようなものをクライアント側に保存することを選択し、それらを定期的に更新する必要がある場合、おそらくあなたを殺したいと思うでしょう。
まったく同じ理由で、適切に一元管理および構成できるテクノロジーを選択してください。使用する中央管理ツールとうまく統合されていることを確認してください。
常に最小公分母を使用してテストしてください。これは、非管理者として、最も原始的なOS、アプリケーションスイート、およびブラウザプラットフォームで一般的に使用されていることを意味します。可能な限り最後の最後に、すべてのユーザーに必要なブラウザーのアップグレードを行うのは好きではありません。
物事がうまくいかないときに私たちを責めるためにジャンプしないでください。私の古い仕事では、アプリが壊れるたびに、開発者はすぐに私たちに指を向けていました。 「新しいパッチをインストールしました。ブラウザをアップグレードしません。セキュリティが厳しすぎます」など。これは破壊的な雰囲気を生み出します。私たちは本当に同じ側にいて、あなたと協力してそれを修正したいと思っていますが、そのような状況ではできません。
コミュニケーション、コミュニケーション、コミュニケーション。システム管理者と開発者の間のすべての問題は、ほとんどの場合、コミュニケーションの欠如にまでさかのぼることができます。プロジェクトの前に、システム管理者（またはその代表者）と開発者が集まり、素晴らしいフレームワークについて話し合った場合、SOOOOOOOOOOO多くの問題を回避することができます。アプリがアプリサーバー+ DBサーバー+インターフェイスサーバーなどに分離されるため、開発中の1つのボックスで全員を開発し、それが本番環境で炎上するのを見るだけなので、どれだけのことが汚されるかはわかりません。このトピックを取り上げてくれたことを称賛します。
エリート主義にならないでください。
"私の時間を無駄にしないでください、バディ。あなたはただの犬の体のシステム管理者です; [〜＃〜] i [〜＃〜]ソフトウェアを書いて- あなた単にサービスを提供するだけです。だから、あなたのささいな懸念に黙って、私が言うように、OK？ "
開発者は実際に一度私にそれらの言葉を言いました（1）。メールで。大規模な配布グループにCCで送信しました。その意味は明らかでした。開発者として、彼はソフトウェアユニバース全体の支配者でありマスターでした。そして私は、彼が貴重な時間を無駄にするにはあまりにも些細な仕事に対処するために雇われた日雇い労働者でした。もちろん、これはほぼ最悪の例ですが、ご存知のように、以前とそれ以降の両方で、多くの開発者からそのコメントの強いエコーと弱いエコーが聞こえました（2）。
あなたは私より多くのお金を稼ぐかもしれません（しかしそれを仮定しないでください！）。ただし、ユーザーが依存するシステムを構築、運用、および保守するには、チームが必要です。最終的に私たちは皆彼らに仕えます。
あなたの仕事とスキルは私のものとは違うと思います。私はあなたの能力を尊重します。初歩的でバカに見えても、私の質問に答えてくれるといいのですが。この礼儀を元気に返します！
多くの悪い（または単に気にしない）開発者がさまざまなフォーラムで発言し、考え、投稿しているので、私は狂ったパワートリップに参加していません。しかし、私の懸念はあなたの懸念とは異なり、私の質問や提案は私のエゴに役立っていません。確かに私の仕事は、アプリを最高の実行状態に保ち、すべてのユーザーが利用でき、応答できるようにすることで、見栄えを良くすることです。そのためには、残りのネットワークとシステムも最高の状態で実行し続ける必要があります。
私はあなたが過去に愚かで、権力に狂った、そして/または単に怠惰な管理者に出くわしたことを完全に知っています。私は一つにならないように、そして一つのように見えないようにしています。この可能性の余地を残し、それを見たときにそれを認めれば、他の嫌いな人が彼らのシステム管理者が何であるかについてまだ発煙している間に、あなたが必要なものを手に入れると確信しています。
（1）彼はまた、彼のプログラム（ソフトウェア要件を記述および管理するためのツール）がインストールおよび実行するためにドメイン管理者特権を必要とすることを主張していました。それはメジャーセキュリティリスクでした。
（2）私はまた、必要なときに教え、必要なときに学ぶことができる多くの素晴らしい開発者と協力してきました。
システム管理者にはやるべき仕事があることを尊重し、彼らに仕事を任せます。多くの企業には無能なシステム管理者がいて、これはしばしば現実的ではありません。しかし、システム管理者がその能力を証明した後でも、傲慢な開発者がシステムグループのアドバイスを無視しているのを見てきました。
新しいシステムの設計について、sysadminsと話し合います。多くの場合、貴重な洞察があります。開発者は、システム管理者との話し合いをよく見て、初期要件を「時期尚早の最適化」としています。私は実際、開発グループの責任者が、新しいデータベースサーバーの要件について、書き込みが多いか読み取りが多いかを説明する範囲でさえ、sysadminやDBAと話し合うのは時間の無駄だと言っているのを見ました。必要なストレージの量。
システム管理者とパフォーマンスの問題について話し合います。正直なところ、システムのパフォーマンスメトリックを適切に解釈できるのはシステム管理者だけです。 「free」の出力が10回説明された後でも、「free」によって報告される空きメモリは常に減少するため、開発者はLinuxが常にメモリリークを起こすと判断しているのを見てきました。
システム管理者と話し合うことなく結論を出さないでください。開発者が「データベースは常にディスクバウンドである」（iostatが存在することすら知らなかった）、「RAID 5はトランザクションワークロードに対してより高速である」（移動された1つのデータベースシステムの回想に基づく）などの理論に固執するのを見てきました。あるハードウェアプラットフォームから別のハードウェアプラットフォームへ-読み取りが集中するワークロードであり、RAID5ソリューションでは、より多くのコントローラーに分散されたドライブがますます高速になりました。しかし、これらの詳細を忘れて、結論を覚えているだけでした。）
システム管理者と話し合うことなく、システムの問題の解決策を設計しないでください。私は、開発者がソリューションを設計し、小さな実装支援を求めてくる1つの病的な環境で働いていました。私以外のUnixグループのメンバー、Unixグループの責任者、および彼の上司は、開発者を、インフラストラクチャ全体を機能させようとする同僚としてではなく、「顧客」として扱いたいと考えていました。顧客が常に正しいということは、彼らが何をしているのか、またはその理由を疑わないことを意味しました。正しい解決策を決定できるように、問題を説明してもらうことを主張したのは私だけでした。このような病理学的環境を作り出すような行動をとらないでください。それは正味の利益にはなりません-代わりに、システム管理者は防御的に行動し、誰もが苦しむでしょう。
あなたはもう学校にいません。これらは実際のシステムであり、理想的な方法で動作しません。たとえば、すべてのレイテンシがゼロというわけではありません。システム管理者が、クラスタリングソリューションは政治的な目的のみであり、システムの複雑さが増すと全体的な信頼性が低下することを警告する場合は、真剣に受け止めてください。実際の障害モード用に設計する必要があります。たとえば、TCP経由で通信しているサーバーを失った場合、接続はおそらくリセットされません。システム管理者は、実際の障害モードを理解しています。
あなたのシステム管理者があなたに言うことを聞くか、あなたのシステム管理者が無能であり、解雇される必要があると経営陣に不平を言います。システム管理者を無視しても意味がありません。
アプリケーションをどのようにデプロイするかを検討してください。これについてシステム管理者と話し合うことは理にかなっていることを理解してください。同一のサーバーが100台あり、単一の構成ファイルのみに基づいて異なる場合は、これらの構成ファイルのマスターコピーを中央の場所に保存することを検討してください。アプリケーションを簡単に再デプロイできる場合は、誰もがどれほど優れているかを実感してください。システムに問題がある場合は、1分以内にスペアに再展開するか、壊れたシステムが修復されるまでしばらく待ちますか？アプリケーションを再デプロイできれば、OSをより簡単かつ安全にアップグレードできます。あなたは将来これを気にするかもしれません。
OSが原因であると思われる問題がある場合は、すぐにsysadminを呼び出して確認することをお勧めします。しかし、大雑把な調査で何も明らかにならなかった後、あなたには問題を説明する義務があります。
「ゆっくりと応答する」と「まったく応答しない」には違いがあることを理解してください。
開発中のOS（en）に合わせて変更する予測可能な方法を使用して、予測可能な方法で設定およびレイアウトします。これはすべてを意味します。例：OpenLDAPにはログレベルを実行する奇妙な方法があります。特定のIMAPサーバーには構成ファイルすらありませんが、オプションをコンパイルする必要があります。一部のパッケージでは、特定のディレクトリパスにコンテンツを配置する必要があります。これにより、必然的に特定のオペレーティングシステムの規則が破られます。これらはすべて、私の通常の構成の疣贅として際立っています。
これは一般的なルールですが、あなたが特別であるとは限りません。したがって、ソフトウェアに固有の十分な理由がない限り、ソフトウェアパッケージがプラットフォーム上で一般的にどのように機能するかという一般的な慣習を破ることができます。 「これはそうあるべきだと強く感じています」は、みんなの通常の設定を破るには十分ではありません。それはあなたのソフトウェアが実行しようとしている機能に関連する理由でなければなりません。
アプリにサーバー間通信が含まれる場合は、設計段階で少なくとも1人のシステム管理者を含めてください。また、SQL、SMTP、HTTPなどの他のサービスへの依存関係を明確に文書化します。何をしているのかを推測させないでください。期待どおりに機能しない場合は、サポートできません。
自動化された方法で数十または数百のシステムにソフトウェアを展開できるようにしてください。組織がソフトウェアパッケージを必要としている場合、システム管理者はほぼ確実に、すべてのボックスに手動でインストールする時間がありません。ファイルにライセンス情報が必要な場合は、それを提供する方法を文書化することは大きなメリットになります。
アドビには歴史的にいくつかのインストーラーがありました 作業するのは本当に苦痛でした ;それ以上に狙ってください！
ここで他のすべてを超えて...
- シミュレートされた本番環境（開発サーバーまたはライブサーバーと同じ構成のVM））を要求し、それを使用してリリースプロセスをテストします。次に、このリリースプロセスを提供します。変更のリストとそれらを適用する順序（つまり、1。メンテナンスモードに入る、2。SQL更新を適用する、3。ソースをXバージョンに更新する、4。メンテナンスモードを終了する、5。祈る）
- データの整合性を維持するためにユーザーを追い出すことができるメンテナンスモードがあることを確認してください。ユーザーがログインしてトランザクションを実行している複数のサーバーで大規模なシステム更新を実行することは望ましくありません...これはほとんどの場合失敗のレシピです。
- ある程度標準化された開発モデルを使用します。たとえば、作業中のすべての新しいアプリケーション（Webグループ）はZendFrameworkを使用しています。
- 変更の範囲を把握するために検索できる修正済みのバグのリストなど、読み取ることができる変更ログを提供してください。視点が異なるという理由だけで、潜在的な問題を特定できる場合があります。
非現実的ではありますが、開発者が世界に解放される前に、本番のsysadminまたはdbaの役割で作業することを余儀なくされた場合に役立ちます。
私が扱っている非常に多くの特殊なアプリケーションは、管理された環境へのインストールについての手がかりがないか、データベース設計の残虐行為を犯しています。
初日からスケーリングについて考えてください。システム管理者は、パフォーマンスの問題にお金やハードウェアを投入することで驚異的なことをすることができますが、これらの量が役に立たない場合もあります（特にロックについて考える場合）。ロックの問題から自分自身を購入できない場合もあります。質問してくれてありがとう:)
ああ、可能な限り64ビットで、マルチスレッド化するようにしてください:)
運用のための設計。
- スペックなしで開発しないでください
- 文書化する（または文書化する人が正確に行うようにする）
- お客様をサポートすることを恐れないでください（より高いレベルのサポートとして）
私の経験では、開発者が1日目からデプロイを検討する場合に最も大きな違いがあります。本番/顧客環境で新機能を考え始めたらすぐに、それをどのようにデプロイするかを考え始めます。環境、およびそれがどのように実行されるか。
彼らが開発プロセスに入ると、手遅れではありませんが、彼らがそこまで視点を変えることができるようになるまでには時間がかかることがあります。彼らは、コードベースに立ち向かうことを余儀なくされるまで、コードベースをどれほど抽象的に見ているかを理解していません。彼らの心の中では、それは単なる「コンポーネント」です。特に興味深いのは、ソフトウェアの以前の（または古い！）バージョンを実行して、既存の環境にどのようにデプロイされるかです。展開に関する議論は、新しい機能に対応するためにアーキテクチャを調整する方法に大きな影響を与える可能性があります。
1）エラーを詳細に記録するログファイル。またはELMAHのような優れたエラー追跡システム。
2）インストール、実装、およびSAガイド）の詳細なドキュメント。
3）さらに他の素晴らしいSAからの上記のもの。 :)
私が今考えることができるのはそれだけです。
この本 Release It！ には、制作で何がうまくいかないかについてのホラーストーリーの素晴らしいセレクションがあります。それを読むことは、操作を念頭に置いて設計するためのインスピレーション/アイデアを提供することができます。 （これは、開発と運用の両方の側面に携わってきたMichael Nygardによって書かれました。）
私がまだ見たことがないのが好きなものは構成可能です。あらゆる種類の構成ファイルを使用するアプリがある場合は、すべてを構成可能にします。
私の会社では、データベースの一部をエクスポートする簡単なアプリを作成しました。翌週、小さな部分をオフにできるように書き直していました。それ以来毎週、小さな機能を変更するためだけに、パーツを書き直して再構築する必要がありました。 xml構成ファイルをほとんど追加しなかったので、再デプロイがはるかに簡単になりました。
設定ファイルが大好きです。
開発者がQAタスクからより適切に分離されることを願っています。開発者が自分が取り組んでいるプロジェクトの単体テストケースをいくつか作成できればいいと思いますが、それらのテストがQAに渡されればいいと思います。実際、開発者がQAエンジニアに少しの助けを与えるとき、それは最終的にDEVに利益をもたらすので、それは素晴らしいことです。
サポート可能であることを確認してください：ここに記載されている他のすべてに加えて、SO -- https://stackoverflow.com/questions/205374/what-are-the -core-elements-to-include-in-support-documentation /