実稼働サーバー（メール、Web、データベースはすべて1つのサーバー上にある）とテストサーバーの両方を管理する責任があります。どちらもDebian上に構築されています。しかし、システム管理は初めてなので、新しい機能を使用してバグを修正するために更新する必要があるものに出くわしたときに、更新プログラムをインストールしているだけです。現時点では非常にアドホックなプロセスであるため、それを減らしたいと思います。
だから私は自分が何をしているのかを知っている人がこれをどのように扱っているのだろうか？サーバーでどのくらいの頻度でアップグレードを実行しますか？アップグレードプロセスはテストと本番で異なりますか？常に最初にテストサーバーをアップグレードしますか？そして、すべてのソフトウェアの完全な更新を行いますか、それとも選択した更新のみをインストールしますか？
回答:
apt-get update -qqを実行します。apt-get upgrade -duyqを毎日。これにより、更新が確認されますが、自動的には更新されません。
その後、視聴中に手動でアップグレードを実行し、問題が発生する可能性のあるものを修正できます。
パッチを適用したシステムを維持することのセキュリティ上の懸念に加えて、パッチとパッチの間隔を長くしすぎると、アップグレードしたいパッケージが大量にあることに気づきます。毎週2つほど。したがって、アップグレードは毎週実行するか、優先度が高い場合は毎日実行する傾向があります。これには、どのパッケージがシステムを壊したかを知るという追加の利点があります（つまり、一度にカップルしかアップグレードしない場合）
重要度の低いシステムを最初にアップグレードします。システムを修正できない場合に備えて、「ロールバック計画」も用意しています。（ほとんどのサーバーは仮想であるため、このロールバック計画は通常、アップグレードの前にスナップショットを取ることで構成されており、必要に応じて元に戻すことができます）
そうは言っても、過去4年間でアップグレードによって何かが壊れたのは1、2回だけだと思います。これは高度にカスタマイズされたシステム上で行われたものです。
以前の回答に加えて、さらに具体的にはDebianの事柄：debian-security-announceとdebian-announceを購読するか、Debian Securityページをチェックしてください。
Debianの安定版リリースを実行していると仮定すると、ほとんどのパッチはセキュリティまたはバグ関連であり、特定のパッケージのバージョン間で大きな変更があまりないことを意味します。debianパッチポリシーによると、パッチはメンテナーによって安定版ブランチに移行されるまでしばらくテストされているはずです。明らかに、これはパッチを当てたときに破損を止めることはありませんが、ほとんどの場合それらを防ぐはずです。
テストサーバーを最新の状態に保ち、あなたとサーバーに影響を与えるバグのあるパッケージは常に最新の状態に保つようにしてください。セキュリティアドバイザリのあるすべてのパッケージは、パッチが安定していることがわかったらすぐに更新する必要があります。
Debianは通常非常に安定したOSであり、破損を過度に心配する必要はありませんが、更新される前に常に更新される内容を読んで、奇妙に思われるものに注意してください。/ etc / dirでもVCSを使用して、「git diff」コマンドで設定ファイルの変更を確認できるようにします。
何が更新されるかを確認するために、最初にドライランを実行します。時々、ライブラリ（この例ではlibfooと呼びます）がAPIを変更し、自分で作成/インストールしたプログラムを壊します。いくつかの重要なライブラリが更新された場合、ソースを取得し、更新する前にそれに対してリソースを再構築してみます。
また、Apacheなどの一部のパブリックサービスの中間バージョンにジャンプしていないことも確認します。更新が重要でない限り、1年遅れてランダムな破損が発生しないようにします。
システム管理者であれば、SecuniaなどのサイトからRSSフィードを取得する必要があります。これにより、ディストリビューションがパッチをプッシュする場合に、事前に通知する必要があります。
盲目的にアップグレード/アップデートすることは絶対にしないでください。残念なことに、特にシステムがプログラマをサポートしている場合、何が壊れているかを知る作業は、ディストリビューションパッケージマネージャではなく、あなたにかかっています。
私が働いている場所には、PatchLinkと呼ばれるソフトウェアを使用して最も重要なセキュリティ関連の更新を通知する非常に広範なプロセスがあり、テスト後にパッケージごとに適用します。ただし、数千のサーバーがあります。
サーバーが2台しかない場合、プロセスははるかに簡単になります。「apt-get update / upgrade」を行うのが最善策だとは思いませんが。
私はあなたが実行しているソフトウェアのパッチを監視し、アップグレードする時期に関するそれらのリリースの修正に基づいて決定を下します。
テストサーバーがあるため、明らかに、更新プログラムを適用する前に必ずテストしてください。
手動での更新は、何が起こっているのかを見ることができるという意味で、ここで述べたように最適です。ただし、非常に多数のサーバーでは、実用的ではなくなる可能性があります。ドライランは標準的な方法であり、実際、ほとんどのパッケージマネージャーは先に進む前に尋ねてきます。
定期的に更新するのが最善である傾向がありますが、それは少しバランスのとれた行為かもしれません。頻繁な更新は、一度に少なくなることと、一度に間違って進むことを少なくすることを意味します。物事がうまくいかない場合、検査する候補者が少なくなります。パッケージは、通常、プログラマが最終バージョンから次のバージョンに移行するときに更新するとき、最後のバージョン以降に注意を払うかどうかは異なる可能性があるため、小さなステップでの更新がわずかに優れています主に急速に進化しているソフトウェア向けです。
すべての更新が中断しないわけではありません。これには気をつけてください。一部のサービスはサービスを再起動し、ダウンタイムを引き起こします。
理想的なセットアップでは、次のものがあります。
これらのいくつかは、小規模なセットアップではさまざまな程度に過剰になりますが、留意する必要があります。
一般的に、更新プログラムは通常、サーバーディストリビューションでは比較的簡単です。これは、ほとんど常にバグ修正とセキュリティ更新のみに固執しているためです。ただし、人々がシステムに奇妙なことをした場合、または追加のパッケージソースを追加した場合、問題が発生することがあります。
ややまれですが、時々ミスをして、マイナーパッケージバージョン間の互換性を損ないます。
私はこのプロセスを自動化するcron-aptが好きですが、@ dinomiteが更新に関する別の質問で指摘したように、セキュリティ関連の更新を自動化するように特別に構成することは非常に賢明なアイデアです。その後、必要なものを手動で更新できます。私はすべてのアップデートにcron-aptを使用していましたが、実際には彼の答えに基づいてこれを変更しました。あなたがそれを好めば、おそらくこれよりも彼の答えを投票するべきです。
cron-aptと同じ行に沿って、unattended-upgradesパッケージhttp://packages.debian.org/lenny/unattended-upgradesをご覧ください。
構成が非常に簡単で、セキュリティ更新プログラムを自動的にダウンロードして適用できますが、手動アップグレードのために他の更新プログラムを残すことができます（または自由裁量ですべてをアップグレードします！）。
公式Ubuntuサーバーガイドには、無人アップグレードパッケージhttps://help.ubuntu.com/9.04/serverguide/C/automatic-updates.htmlの使用をカバーするかなり詳細なセクションがあります。
注：注意レベル/パラノイアのレベルに応じて、最初にテストサーバーのグループでローリングアップグレードを実行し、問題がない場合は、運用ボックスの更新を許可しますが、私は個人的にセキュリティアップデートで問題に遭遇することはありませんこれまでの破壊（木材のノック）...
また、適用されたセキュリティ更新プログラムの結果をメールで送信するための構成オプションもあります。また、更新中に表示されたダイアログまたは対話型のプロンプト（システム管理者による手動調整が必要なプロンプト）があった場合、それらも同様に言及されます。
私は個人的に自動更新をオフにし、次の場合を除き、環境内のサーバーでパッケージの更新を定期的に実行しません。（b）特定の理由で個々のパッケージをアップグレードする必要があります。（c）OSまたはパッケージがサイクルの終わりに近づいているため、サポートされなくなり、サポートを継続する必要があります。私の理由は、何が変更されているのか、なぜ壊れているのかという余地を残していないままアップグレードすることです。私はこのようなことを14年間続けてきましたが、うまくいきます。