システム管理者および開発者：責任[終了]

実稼働Webサーバーのようなものになると、システム管理者と開発者の責任に関するベストプラクティスは何ですか？具体的には、ソフトウェアの更新/インストールについて考えています。（私の理解では、開発者は実稼働サーバー上でrootアクセスを持ってはいけません。）

そのため、実稼働WebサーバーでWordpressが実行されており、最新バージョンに更新する必要があります。誰がそれを更新し続ける責任がありますか？

開発者がカスタムハッキングされたプラグイン、またはアプリ（この例ではWP）にカスタムコアファイルを持っている場合はどうなりますか？

ほとんどの場合、物理サーバーの責任者があなたである場合、開発者にルートアクセス権を与えないことが最善であることがわかりました。

これはちょっとした「聖戦」論争であり、意見の違う開発者を見つけるだろうと確信しています。私は個人的にその議論の両側にいた。

開発者（100％信頼できる開発者であっても）にルートアクセス権を与えない主な理由は、XYZを正常に機能させるために必要なパッケージがある場合が多いためです。彼らは先に進み、それをインストールします...または既に機能しているように何かを再構成します...または...まあ...あなたはアイデアを得ます。

数か月経つと...サーバーを再インストールまたは再作成する必要があります...そして突然、「古いサーバーでは機能するが新しいサーバーでは機能しない」理由が誰にもわかりません。

もちろん、あなたが見ているドキュメントには、開発者が最初にシステムを動作させるために行った小さなパッケージや微調整がすべて含まれているわけではないということです。

双方にとってa $$が苦痛になる可能性があります...しかし、システム管理者がサーバー、パッケージ、ドキュメントを担当し、開発者が開発とソフトウェアを担当する場合...結局それは価値があるとわかるでしょう。

開発者がカスタムプラグイン、モジュール、構成、調整が必要な場合は...問題ありません...それらのためにそれを実行してください...しかし、次回それを再現できるようにドキュメントを作成してください。

黄金律：非管理者に、あなたが壊れたくないものや、あなたが責任を問われるものに触れさせないでください。

開発者はテスト環境にアクセスできる必要があります。それらの作業が本番マシンに配置される準備ができたら、システム管理者に引き渡す必要があります。開発者が作業を完了し、手順を適切に文書化すれば、すべてうまくいきます。そうでない場合は、適切にテストしないために裏側をキックする必要があります。

私もこの戦いに参加しています。私の答えは、サーバーの稼働時間を担当する人が、すべての更新、変更などを担当する人であるということです。他のNobodoyは、サーバー上でこれらのタイプの機能を実行できる必要があります。サーバーが稼働していることを確認するのがあなたの仕事であり、上司がサーバーの責任と責任を負っている場合、それを維持し保護するのはあなたの責任です。

ほとんどの開発者は、サーバーへの管理者レベルのアクセスが必要であり、ほとんどの人が私に同意しないことを伝えますが、私はハングアップしたときに午前2時に再起動する必要があり、再構築する必要があります更新の失敗、ダウンタイムは部門などに請求されます。SLAに影響を与えるものについてはCIOに回答する必要があるため、サーバーへの管理者レベルのアクセスを取得できるのは私だけです。 mすべてのコンポーネント、更新、変更などを担当します。

私は100％同意します。開発者はほとんどの場合、syadminがどのように機能するかを認識していません。彼らが何かを必要とするならば、彼らはあなたに尋ねます、それがすべてです。いつどのように使用可能なパッケージを提供するかを考えます。（彼らが電子メールを送信する必要があるように、あなたが後置を設定するのはあなたです）。さらに、通常のアクセスではできない場合、ほとんどの場合、rootアクセスは物事を機能させると考える傾向があります。私はここで他の人に同意します、彼らがあなたが問題を見るであろう午前2時にあなたと一緒ではないでしょう。数週間前、私は開発者がワードプレスを更新したいと考えていました。役に立たなかったRTFのchangelogに彼に言った、それは更新プロセスは美しいインターフェイスを介して行われます。更新はうまくいきませんでした。彼のアプリケーションを保存し、彼ではなくバックアップスクリプトを作成しました。私がいなければ、彼はサイトを復元できなかったでしょう。

開発と運用の区別を曖昧にする傾向があります。開発者をシステム管理者にし、システム管理者を開発者にします。

この意味で、ワードプレスは、ブログの自動化された（およびプログラム的な）提供に関するいくつかの作業から恩恵を受けることができます。多くのワードプレスユーザーは、いくつかのWP / WPMUインスタンスを維持しており、それらをタイムリーに更新することは少なくとも面倒です。

Agile 2009のAgile Infrastructureスライドで、哲学の素晴らしい（そして楽しい）概要を見つけることができます。

開発者は本番環境にルートを持ってはいけません。開発者以外の全員がこれに同意します。しかし、開発者はケーキを用意して食べることもできます。誰もこれを明示的に言及していないことに私はいくらか驚いています：

私の長年の小規模ビジネスクライアントの1つに、DrupalがインストールされているWebサイト、いくつかのWordPressサイト、SMFフォーラム、およびその他のいくつかのランダムな小さなWebアプリがあります。私は契約のシステム管理者であり（また、歴史的な理由から、必要に応じてWordPressとSMFを更新/ハックします）、私のクライアントには独自の契約Drupal開発者がいます。環境は、パブリッククラウドプロバイダー上の複数のVMware仮想マシンです。

開発者は本当にrootアクセスを必要とし、それを必要としています。たとえば、すべてのカスタムDrupalを機能させるために、nginxの書き換えルールを記述するのは彼らの責任です。しかし、実稼働サーバーでrootアクセス権を与えることは決してありません。クライアントはそれに同意します。

そこで私たちは妥協しました：彼らはテストWebサーバーでルートアクセスを取得します（これはIPアドレスを除いて一般に運用環境と同じで、同じクラウド上にあります）。実稼働と同様にetckeeperがあるため、必要な変更やインストールしたパッケージを確認できます。次に、変更を実稼働環境に取り込むか、何をしたいのか、何が悪いのかを伝えます。そして、彼らが本当に台無しになった場合（彼らはまだしていない、gawdに感謝）私は彼らの変更を簡単に元に戻すことができます。

運用データベースサーバーにはまったくアクセスできません。ユーザーログインさえありません。私のクライアントと私だけです。

（Webアプリ自体は、gitで直接デプロイします。それを破ると、それを修正し、なぜ彼の開発者であり続けるべきかをクライアントに説明します。それらまたはfacepalmで笑います。）

ルート==システム管理者。

ユーザー==開発者、DBA、またはユーザー。

ルートは、サーバーがダウンしてもスリープ状態にならないことを知っています。ルートはユーザーを自分自身から保護し、ルートはユーザーのデータをネットから保護します。サーバーがオフラインのとき、ルートのお尻は回線上にあります。サーバーハッピー、ルートハッピー！

予定外のダウンタイムの一般的な理由：ユーザー、文書化されていない環境の変更、およびバックホウ。サーバーは、ランダムに壊れるのではなく、言われたとおりに動作します。あなたが尋ねるハッカー、その場合ではなく、そのとき...したがって「ルート」の必要性

00:33 CDTは、バックアップおよび災害復旧ドキュメントの場所を知っていますか？:-p

システム管理者には管理者アクセス権が必要です（タイトルに書かれているとおりです）。本番サーバーにアクセスする必要はありません。開発者が運用システムの問題をトラブルシューティングする必要がある場合、その問題は開発環境で再現可能である必要があります。そうでない場合は、システム管理者と一緒に座って、システムを確認できます。

開発者はプロダクションに触れることができないことを嫌いますが、それは仕事ではありません。仕事は、ソフトウェアを作成し、製品リリースのためにシステム管理者に引き渡すことです。彼らがすべてを文書化した場合（そして、ほとんどの店では文書化が汚い言葉であることに留意してください）、リリースはうまくいくはずです。

ここ米国の公開会社では、対処するSOX、HIPPAなどがあります。これらのgodforsaken規制のほとんどは、実際にこの議論に役立ちます。SOXは職務の分離を指示するため、開発者は本番システムから手を離しておく必要があります。