Linux には慣れているつもりでしたが、本番環境でそれがひっくり返されるとは予想もしていませんでした...

長年運用保守に携わっていると、データ損失、Webサイトの不具合、データベースファイルの誤削除、ハッカー被害など、様々な問題に遭遇してきました。攻撃などの問題の種類。また、Linux システムに精通していると思っている友人にもたくさん会いましたが、彼らは問題が発生しても決してパニックにならず、自信に満ちていました。 しかし、本番環境はひっくり返りました (解雇されそうになりました) ＃＃＃、無数にあります。 。 。

そこで、今日は Linux の優れた操作習慣を簡単に整理し、皆さんと共有したいと思います。安全に操作し、

決して横転しないようにしましょう。 ！

オンライン操作仕様

テスト使用

Linuxを使用する場合「基礎からサービス、クラスタまで、すべて仮想マシン上で行われることを初めて学びました。先生は実機と変わらないと言っていましたが、実環境への欲求は日に日に高まっています。しかし、仮想マシンのさまざまなスナップショットは、機械は私たちにさまざまなスキルを開発させてくれました。私には悪い癖があり、サーバーを操作する許可を得たとき、それを試すのが待ちきれませんでした。勤務初日に上司が私にルートを与えたのを覚えていますputtyしか使えなかったのでxshellを使いたかったのでこっそりサーバーにログインしてxshellキーログインに変更してみました テストもなくssh接続が残っていなかったため sshdサーバー再起動後, サーバーからブロックされました。幸いなことに、その時点で sshd_config ファイルをバックアップし、後でコンピューター室のスタッフに CP を通過するように依頼しました。幸いなことに、これは小さな会社です。そうでなければ、私は直接殺されていたでしょう...あの時はもっと運が良かったので良かったです。

2 番目の例はファイルの同期に関するものです。rsync は同期が速いことは誰もが知っていますが、ファイルの削除速度は rm -rf よりもはるかに速いです。rsync には特定のディレクトリに基づくコマンドがあります。ファイルを同期すると (最初のディレクトリが空の場合、結果は想像できます)、ソース ディレクトリ (データのある) は削除されます。最初は、誤操作とテスト不足のため、ディレクトリを逆に書きました。重要なのは、バックアップがありません... 本番環境のデータは削除されており、バックアップはありません。結果については自分で考えてください。その重要性は自明です。

入力前に何度も確認してください

エラー「rm -rf / var」については、手が早い人やインターネットの速度が比較的遅い場合に発生する可能性が高いと思います。死刑執行が完了したことがわかったとき それ以降、あなたの心は少なくとも半分冷めたように感じました。 「何回も押したのだから心配しないでください。一度起これば分かります。これらの運転保守事故がすべて原因であるとは考えないでください。」注意を怠ると、次のことが起こります、それはあなたです。

複数人での運用はやめましょう

私が前に勤めていた会社の運用保守管理はかなり混乱していました。最も典型的な例を挙げると、運用保守担当者が何人も辞めてしまいました。サーバーの root パスワードがあったときがあります。通常、運用保守の仕事を依頼されると、簡単なチェックを行い、解決できない場合は他の人に助けを求めますが、問題が深刻な場合は、顧客サービスの責任者（Linux の知識がある）が担当します。ネットワーク管理者とあなたの上司が一緒にサーバーをデバッグします。さまざまな比較の結果、サーバー構成ファイルが最後に変更したときとは異なることがわかりました。その後、変更を元に戻し、再度 Google で検索しました。問題が見つかりました。で解決しましたが、他の人も解決したと言っています。変更されているのはパラメータが異なるだけです...これでは、どれが問題の本当の原因であるかはわかりません。もちろん、これはまだ良いです。問題は解決され、全員が満足しています。しかし、変更したばかりのファイルに遭遇し、テストは無効です。変更しようとして、ファイルが再度変更されていることがわかったらどうなりますか?これは非常に面倒なので、複数人で行うべきではありません。人々。

バックアップしてから運用する

習慣を身につける データを修正したいときは、まず .conf 設定ファイルなどをバックアップしてください。また、設定ファイルを変更する場合は、元のオプションをコメント化してからコピーして変更することを推奨します。また、最初の例でデータベースのバックアップがあれば、rsync の誤操作は問題ありません。一夜にして起こるものではなく、ただ偶然に起こることです。バックアップがあれば、それほど悲惨なことになる必要はありません。

データの関与

rm -rf の使用には注意が必要です

インターネット上には、さまざまな rm -rf /、さまざまな削除の例が多数あります。メインデータベース、さまざまな 運用保守事故の一種…小さなミスが多大な損失を引き起こします。どうしても削除する必要がある場合は、注意してください。

バックアップ運用は何よりも重要です

本来、上記にはさまざまな種類のバックアップがありますが、バックアップが非常に重要であることをもう一度強調するために、データのカテゴリに分けたいと思います。 「データに関しては、どんなに注意を払っても誇張することはできません。私が働いている会社には、サードパーティの支払い Web サイトとオンライン ローン プラットフォームがあります。サードパーティの支払いは 2 時間ごとに完全にバックアップされており、オンライン ローン プラットフォームは、ローン プラットフォームは 20 分ごとにバックアップされます。多くを言う必要はありません。自分で決めましょう

安定性はすべてよりも重要です

実際には、データだけでなくサーバー全体もバックアップされます。環境では、安定性が何よりも重要です。最速を求めているわけではありませんが、最も安定しています。使いやすさを追求しているため、nginx php-fpm などの新しいソフトウェアをテストせずにサーバー上で使用しないでください。本番環境では、 , php はさまざまな方法でハングしますが、再起動するか、Apache を変更するだけです。

機密性は何よりも重要です

現在、あらゆる種類のポルノ写真があらゆる場所に存在し、あらゆる種類のルーターのバックドアが存在します。秘密にしておいてください。さらに、パブリック アカウント Linux を検索するときに、バックグラウンドで「Linux」と返信してサプライズ ギフト パッケージを入手する方法を学ぶ必要があります。

セキュリティ関連

ssh

デフォルトのポートを変更します (もちろん、専門家があなたをハッキングしたい場合は、スキャン後に判明します)。ログインして通常のユーザー キー認証 sudo を使用する ルール IP アドレス ユーザーは、hostdeny のような防爆クラッキング ソフトウェアの使用を制限されます (数回以上の試行はユーザーを直接ブロックします) /etc/passwd

にログインするユーザーを選別する

ファイアウォール

運用環境ではファイアウォールを有効にする必要があり、最小限の原則に従ってすべてを削除し、必要なサービス ポートを解放します。

細かい権限と制御粒度

一般ユーザーが起動できるサービスにはrootを使用せず、各種サービスの権限を最小限に抑え、細かい粒度で制御します。

侵入検知とログ監視

サードパーティ ソフトウェアを使用して、/etc/passwd、/etc/my などの主要なシステム ファイルやさまざまなサービス構成ファイルの変更を常に検出します。 cnf、/etc/httpd/con/httpd.con など、集中ログ監視システムを使用して、/var/log/secure、/etc/log/message、ftp アップロードおよびダウンロード ファイル、その他のアラーム エラー ログを監視します。さらに、ポート スキャンの場合は、サードパーティ ソフトウェアを使用することもできます。スキャンされたことが判明した場合は、host.deny に直接取り込まれます。この情報は、システムが侵害された後のトラブルシューティングに非常に役立ちます。企業がセキュリティに投資するコストは、セキュリティ攻撃によって損失するコストに正比例すると誰かが言っています。セキュリティは大きなテーマであり、非常に基本的な仕事です。基本が適切に行われていれば、システムのセキュリティは大幅に改善できます。残りはセキュリティ専門家が行います

日常監視

システム運用監視

多くの人は から始めることが多く、大企業では一般に監視から始めます。専門的な24時間監視と運用。システム動作監視には一般に、ハードウェア占有率、メモリ、ハードディスク、CPU、ネットワーク カード、ログイン監視や主要なシステム ファイル監視を含む OS が含まれ、定期的な監視によりハードウェア損傷の確率を予測し、チューニングに非常に実用的な機能をもたらします。

サービス運用監視

サービス監視とは、一般的にさまざまなアプリケーション、Web、DB、LVS などを指します。これは通常、いくつかの指標を監視し、システムでパフォーマンスのボトルネックが発生した場合に迅速に発見できます。そして解決しました。

ログ監視

ここでのログ監視はセキュリティログ監視と似ていますが、一般的にはハードウェア、OS、アプリケーションのエラーやアラーム情報の監視です。 、それは問題ではありません、役に立たないのですが、一度問題が発生して監視しないと、非常に消極的になります。

パフォーマンス チューニング

動作メカニズムの深い理解

実際、1 年以上の運用および保守の経験に基づいて、チューニングについて語るのは基本的には紙の上で話すだけですが、簡単に要約したいだけです。より深い理解が得られたら更新します。たとえば、ソフトウェアを最適化する前に、nginx や Apache などのソフトウェアの動作メカニズムを深く理解する必要があります。誰もが nginx が速いと言っています。ですから、nginx がなぜ速いのか、nginx がどのような原理を使用しているのかを知る必要があります。 、Apacheよりもリクエストを処理する方法、そして他のものと競争できなければなりません、平易でわかりやすい言葉で言えば、必要に応じてソースコードを理解できなければなりません、そうでなければパラメータを使用するすべてのドキュメントが理解できなければなりませんチューニングオブジェクトはナンセンスだからです。

チューニング フレームワークとシーケンス

基本的な動作メカニズムを理解したら、チューニング フレームワークとシーケンスを理解する必要があります。たとえば、データベースにボトルネックがある場合、多くの人はデータベースの構成ファイルを直接変更します。私の提案は、最初にボトルネックを分析し、ログを確認し、チューニングの方向を書き留めてから開始することです。データベース サーバーのチューニングは最後のステップである必要があります。最初に行うべきはハードウェアとオペレーティング システム。今日のデータベース サーバーはすべて、さまざまなテストを行った後、すべてのオペレーティング システム用にリリースされるため、最初から使用する必要はありません。

牛逼啊！接私活必备的 N 个开源项目！赶快收藏

一度に 1 つのパラメータのみを調整してください

一度に 1 つのパラメータのみを調整してください。これは誰もが知っています。調整しすぎると混乱します。

ベンチマーク テスト

チューニングが有用かどうかを判断し、新しいバージョンのソフトウェアの安定性とパフォーマンスをテストするには、ベンチマーク テストが必要です。テストには多くの要素が含まれ、適切かどうかをテストします。ビジネスに近い 実際の需要はテスターの経験に依存します 関連情報については、非常に優れた「High Performance MySQL」の第 3 版を参照してください。私の先生はかつて、「万能のパラメータなど存在しない。パラメータの変更や調整はビジネス シナリオに準拠する必要がある。だから、これ以上調整しないでください。改善に長期的な影響はありません」と言いました。ビジネス環境の改善。

運用と保守の考え方

コントロールの考え方

多くの rm -rf /data は、降車後の最初の数分間でイライラのピークに達します。仕事をしているから、自分のメンタルをコントロールするつもりはありませんか? イライラしていても仕事に行かなければならないという人もいますが、イライラしているときは重要なデータの処理を避けるようにしてください。 、もっと冷静にならなければ、より多くの損失を被ることになります。ほとんどの人は rm -rf /data/mysql を経験したことがあります。削除した後の気持ちは想像できると思いますが、バックアップがなければ、不安になっても仕方ありません。通常、この場合は落ち着いて対処する必要があります。最悪の事態に備えてください。mysql の場合、物理ファイルを削除しても、一部のテーブルがメモリ内に残るため、ビジネスを切断しますが、mysql データベースは閉じないでください。これは回復に非常に役立ちます。 dd を実行してハードディスクをコピーすると、復元が可能になります。もちろん、ほとんどの場合、データ復元会社しか見つかりません。データが削除された場合、データベースを閉じて修復するなどの操作を行うと、ファイルが上書きされるだけでなく、メモリ内のテーブルが見つからなくなる可能性があります。

データに責任を持ちましょう

運用環境は簡単なものではありませんし、データベースも簡単なものではありません。データに対して責任を負わなければなりません。バックアップを行わなかった場合の結果は非常に深刻です。

問題の根本に迫る

多くの運用保守担当者は多忙で、問題が解決しても対処しようとしません。昨年、顧客の Web サイトで問題を解決できなかったのを覚えています。 PHPコードのエラーレポートでセッションとwhos_onlineが壊れていたことが分かりました 前回の運用保守では修復で直ったのでこの方法で修復しましたが、数時間後、3、4時間経つとまた再発してしまいましたまず、myisam のバグは次のとおりです: 2 つ目は mysqlbug で、3 つ目は書き込みプロセス中に mysql が強制終了されたことです。メモリが十分ではないことが判明し、OOM によって mysqld プロセスが強制終了され、スワップ パーティションが存在しませんでした。バックグラウンド モニタリングのメモリは十分であり、最終的に物理メモリをアップグレードして問題を解決しました。

テストおよび運用環境

重要な操作の前に必ず使用しているマシンを確認し、ウィンドウを開きすぎないように注意してください。

以上がLinux には慣れているつもりでしたが、本番環境でそれがひっくり返されるとは予想もしていませんでした...の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。