プログラマーが働く世界は、適切なコードの世界です。 もちろん、それには無数のエラーがありますが、これらのエラーは修正する必要があります。 これらが他の人のコードで修正できないエラーである場合、それらを文書化し、コードで考慮する必要があります。 しかし、間違いは常にそれを見つけて排除する機会です。
システム管理の世界は異なります。 「そのまま」のコードは次のとおりです。 最小で最も控えめなインストールであっても、すべてのパッケージのソースコードを垣間見ることさえ不可能です。 300 MB以上のLinux、メインライブラリおよびプログラムのソースコード...原則として、無限です。 特定のプログラム、プログラムの特定の場所を知ることはできますが、ランタイム全体、OSを構成するすべてのソフトウェア環境を知ることは不可能です。
そして、それは間違いでいっぱいです。 マットの魅力について好きなだけ話せます。 証拠のコードが、障害がTCPオフロードでのドライバーproprientarnomビデオ（それは思われる、と何がサーバーを持っている？）、またはネットワークカードに発見された場合には役立ちません。
ソフトウェアの問題に対するまったく異なるアプローチがあります-純粋に実用的なアプローチです。 予想どおりに機能する場合があるアプリオリなバグのあるコードがあります。
そして、この「ときどき」を中心に、「安定性」と製品対応の概念全体が構築されます。
私たちは、プログラムがエラーでいっぱいであり、エラーが他のプログラムのエラー、エラーとそれらの不在の組み合わせによって引き起こされる可能性があることを認めます。 異なるプログラムの2つのエラーが相互に中和されることもあります。
私たちはこれを「現状のまま」受け入れ、エラーが発生しない可能性が高い状況に努めます。 間違いが最も少ないのはどこですか？ そうです、彼らが最もテストした場所です。 foobar 1 2が正しい結果を与えることがわかっている場合、ほとんどの場合エラーはありません。 ちなみに、これはfoobar 2 1が正しく機能することを意味するものではありません。 foobar -1 -2、foobar 1.2 2、\\ windows \ path \ foobar 1 2、foobar "01" "02"などは言うまでもありません
つまり、「ソフトウェアテスト」のカテゴリについて話し始めています。 明らかに、すべてのデータを含むすべてのバリアントはテストできませんが、コードのより具体的なブランチをテストするほど、エラーが少ない可能性が高くなります。
そのため、テストが多いほど良いです。
ほとんどのテストプログラムは、ベストプラクティスのデフォルト設定と標準構成で行われます。 あなた自身のことをする理由がない場合、あなたは典型的なことをする必要があります。
ソフトウェアの選択についても同じことが言えます。 基本的な違いがない場合-ディストリビューションでデフォルトで提供されているものを使用する必要があります。 それがより良いというわけではありません-それはちょうどより多く使用されました 。
根拠はありませんが、Selectelの生活から少しだけ有益な話をします。かなり長い間、Python 2.4（centos 5.5ではデフォルト）を使用していました。 プログラマーは多くの盗聴者であり、Python 2.6を望んでいましたが、ダーティーハック（2.6+でのみ動作するライブラリを使用）で最後通告を提示しました。 最初のテストの後、2.6を作業環境に組み込むことが決定されました。
私たちのサービスの大部分は、簡単に落ちるという原則に基づいて実装されています。プログラムが何かを気に入らなくなるとすぐに、外部の再起動サービスで直ちに（制御された方法で）終了して再起動します。 それは非常に広範時のエラー処理ロジックの問題を、コントロールの変化（プール内のクラスタ内のマスターの変更、設定ファイル内のアドレスの変更など）（データベースは、スペースの不足、などは使用できません）解決します。 プログラムの1つは、プールのマスター（プール内で唯一のもの）とプールの他のサーバー（スレーブ）に依存しており、マスターが存在しないことがわかり、静かに終了し、再起動（遅延）して、再び終了しました。 マスターが変更された場合、古いマスターのプログラムは終了してスタンバイモードになり、新しいマスターではわずかに遅れて動作し始めました。
Python 2.4では、うまく機能しました。 Python 2.6が登場しました...そして、アイドル状態のシステムでかなりのCPU使用率が見つかりました。 犯人であることが判明したのはpython2.6でした-（新しいライブラリとともに）python 2.4よりもずっと長く開始しました。
プログラマーの観点から：一体何だ？
システム管理者の観点から：ソフトウェアを新しいバージョンに更新しました-予想外の問題を引き起こしました。
...ところで、問題はプログラムの特別な条件によって解決されました-ウィザードがないため、ウィザードは終了せず、スリープして再試行します。つまり、アプリケーションアーキテクチャを変更し、イージーフォールの原理を部分的に放棄しなければなりませんでした。
些細なことのように見えますが、コードには実際のエラーはありませんが、結果はありますが、特に心地よいものではありません。
したがって、保守のための自然な必要性は、（それが意志聞かせて、と）がある - そしてここで、「腐った」古代のソフトウェアへの分配とソフトウェアのサポートの10年があります。 主な理由は、職場環境の変化に対する恐怖です。
ほとんどのLinuxディストリビューションは、安定版に対するコミットメントの程度によって認定されます。 重要な原則は、ソフトウェアの更新方法です。これは単なるセキュリティ更新であるか、配布キット全体のバージョンを変更せずにソフトウェアを新しいバージョンに更新することを許容することです。
これは、異なるLinuxディストリビューション間の分岐点です。たとえば、ubuntuはソフトウェアバージョンの変更を許可します。 Debian-いいえ。 したがって、Debianはより保守的であり、これだけでサーバーの使用により適しています。 最も保守的なのはRed Hatで、RHEL 4.2は引き続きサポートされています。 正確には覚えていませんが、Linux 2.4のシステムのサポートはまだ完了していないか、近い将来に終了したようです。
そして、もっと何、私はさらに大きなサポートサイクル（15〜20年）とエンタープライズ市場のリリース製品を目指し、予見可能な将来のRHまたは他の誰かにそれを取ることができます。 何のために？ 「一度配信」して、もう考えないようにするため。
ちなみに、サーバーOSの重要な更新に新しいバージョンのブラウザーが含まれているMicrosoftは、明らかに馬鹿げており、安定性のイデオロギーに違反しています。
セキュリティ更新プログラムは必要ですか？
ご存知のように、私はいくつかの構成で興味深い位置を見ました-いいえ。 たとえば、それがそのように機能する場合、どのような状況でもそれ以上触れないでください。 さらに、セキュリティの更新によりソフトウェアの機能が損なわれた実務上のケースがいくつかあります。
ただし、一般的な方法では、バグ修正アップデートをインストールする必要があります。 新しいソフトウェアバージョンからのバグ修正を使用したアップデートの主な違いは、新しい機能がないことです。 エラーのみが修正されます。それ以外の場合は、同じレベルの機能を維持するよう努めます。
出血エッジ
安定性に戻るのは、最先端のコンセプトです。 最新バージョン。 時々、ナイトリービルドからでさえあります（つまり、バージョンではなく、開発中のソフトウェアの中間状態）。 ブリーディングエッジには実際に利点があります。
まず、非定型バージョンを使用しています。 つまり、高い確率で、そのバグはまだ誰にも知られておらず、悪用されていません。 次に、バグの修正が最初に行われます。 第三に、新しい機能は「ペンから」利用可能です。
しかし、これの価格は素晴らしいです-このソフトウェアをテストした人はいません（そしてあなたは安定した壁を構成する倒れた戦士の最前線にいます）、そのバグ、非互換性、愚かさ、タイプミスはすべてあなたのものです。
選択はあなた次第です。 例えば、私は自宅でsidと実験的なDebianの混合物（つまり、ほぼ同じBleeding Edge）、職場のラップトップでは「安定」（比較的）LTS Ubuntu、サーバーではDebian / Centosを使用します。 さらに、新しいディストリビューションのリリースとアップデートの瞬間の間、私は数ヶ月待つことを好みます（時々-古いもののサポートが終了するまで）-この間、いくつかのエラーは新しいディストリビューターで修正され、潜在的な互換性の問題などを解決します 良い方法で、彼らはリリースの発表の前にこれを行うべきでした-しかし、問題をかき集めて眠れぬ夜を過ごすよりも起きているほうが良いです。