管理者にとって、サーバーの再起動は冗談ではありません。 Windowsサーバー管理者にとっては、Windowsデバイスを頻繁に再起動するのが一般的な方法ですが、Unixシステムでは、この方法をデフォルトで再起動しても問題はありません。

Unixサーバー再起動の2つのケース

実際の状況は次のとおりです。サーバー再起動操作はほとんど発生しないはずです。——ごく少数です。ここでは、カーネルの更新とハードウェアの交換を例として挙げています。これらはUnixの世界で再起動が発生する2つの主な原因だからです。サーバーを再起動しないと、深刻なセキュリティ上のリスクが生じると主張する人もいますが、これはナンセンスです。サービスプロジェクトおよびアプリケーションにセキュリティリスクがある場合、脆弱性パッチは問題を解決することができ、パッチはデバイスを再起動するように要求しません。そして、カーネルモジュールにセキュリティリスクが存在する場合、一般的には対応するモジュールをアンインストールし、パッチをインストールし、そして最後にモジュールをリロードするだけで済みます。カーネルにセキュリティ上のリスクがあると、サーバー操作を再開する必要があります。しかし、この状況以外では、Unixサーバーを再起動する本当の理由はありません。

再起動しないと、起動時に重要なサービス項目が正しく有効化されず、一連の隠れた危険性が生じるなど、他のリスクが伴うことがよくあります。もちろん、この記述自体は正しいのですが、管理作業が整っている限り、これは実際には一種の心配です。サーバデバイスを引き継いだばかりの新人だけが、サービスプロジェクトの起動パラメータを正しく設定するのを忘れます。しかし、繰り返しますが、サーバーが構築段階にあり、運用面で問題がない場合は、悪影響を与えずにさまざまな種類の再起動テストを自由に実行できます。そして、私はこれが再起動メカニズムに慣れるための最良の時だと思います。

しかし、考慮すべきもう1つの側面があります。トラブルシューティングで重要なステップの1つとして再起動操作を行う人は、死んだ豚を熱湯を恐れずに保持することであり、一度に問題を明らかにしようとします。問題のある一連のUnixデバイス、まだ実行中のサービスの中には実際には再開できないものがあり、——を再起動すると表示されます。奇妙な理由

Unixサーバーが再起動する理由

デバイスを確認してデバイスを再起動するのに数分かかると、その間に障害の本当の原因は完全に失われます。——おそらく、ジュニア管理者が、誤って/bootディレクトリ、または/etcディレクトリ、/usrディレクトリ、/usrディレクトリ、または/usr /lib64ディレクトリの内容の一部を削除して、一連のバカスクリプトを実行していました。これが、セグメンテーションの失敗や機器の不安定化の原因となります。ただし、問題を掘り下げずにサーバーを直接再起動すると、明らかに問題が深刻になりますので、事故が発生しない場合は、全員がリカバリイメージを開始する必要があります。同時に、本番サーバーも停止状態になります。

これらはUnixの世界で操作を再開しないようにするためのいくつかの理由です。トラブルシューティングの方法ではなく、問題を発見するか、すべてを破壊してゆっくりと再構築するかのような、絶望的なギャンブルの一種と考えることをお勧めします。つまり、エラーを完全に修正するために/varパーティションを使用してデバイスを再起動することはできません。

サーバーを再起動する前に、必要な操作を行ってください。

問題を解決するのに役立つシステム内の重要なコンテンツは、再起動しないことです。再起動する前に存在している必要がありますが、再起動後に存在しない可能性があります。再起動後、問題は確実に再発しますが、再起動動作で解決策が消えた後は、障害自体が解決策のない無限ループに陥ります。誰かが再起動しないと決めない限り、問題の原因を見つけるようにしてください。残念なことに、そのような賢い選択をすることができる人はほとんどいません。実際の状況は次のとおりです。小さな欠陥のあるメモリースティックは、システムの正常な動作とデバイスの起動状態に大きなトラブルを引き起こす可能性があります。現時点では、正しい薬は最善の策であり、再起動は追加の損失をもたらすだけです。

そのため、将来、誰もが問題に直面しているときに、何かを言う人がいたら、最初に再起動したほうがいいでしょう。再起動はもちろん選択肢の1つですが、再起動を実装する前に、考えられるすべての対策を講じていることを確認してください;結局、節約したのは自分の時間とエネルギーです。
zh-CN"],null,[1],zh-TW"]]]