運用担当者がクラウドサーバの障害を処理する方法の概要

私たちのチームはUcloudクラウドコンピューティングサービスに専門家の技術サポートを提供し、毎日無数のユーザーの故障に遭遇しなければならない.基本的にこの過程は私たちに深い記憶を残すほど痛ましい.皆さんが第一線で奮闘している運営者の助けになるための心得も記録されています.
サーバの障害が発生した場合、問題の原因は簡単には考えられません.基本的には、次の手順に従います.
一、できるだけ問題の原因と結果を明らかにする
すぐにサーバーの前に突き刺さらないでください.まず、このサーバーについてどのくらい知っているか、故障の具体的な状況を理解する必要があります.さもないと、あなたは無の矢を放っている可能性が高い.
明らかにしなければならない問題は次のとおりです.

故障の表現は何ですか?応答なし?新聞が間違っていますか.

故障はいつ発見されましたか?

障害は再現できますか?

には、1時間に1回のような法則がありますか?

最後にプラットフォーム全体を更新した内容は何ですか(コード、サーバなど)?

障害が影響する特定のユーザ群はどのようなものですか(ログイン済み、終了済み、ある地域の...)?

インフラストラクチャ(物理的、論理的)のドキュメントは見つかりますか?

モニタプラットフォームはありますか?(例えばMunin、Zabbix、Nagios、New Relic…なんでもいい)

ログを表示できますか?の(例えばLogstackシステムノートのクラウドログサービス)

最后の2つは最も便利な情报源で、特に日志システム、运维者として日志を见るのが上手で得意で、日志は往々にしてあなたが手がかりがない时にあなたに最大の助けをあげて、実は多くの问题はすべて日志システムの中で暴露して、比较的に便利なのはシステムのノートを使うことです
二、誰がいますか.

$ w
$ last

この2つのコマンドを使用して、誰がオンラインで、どのユーザーがアクセスしたかを確認します.これは重要なステップではありませんが、他のユーザーが働いている間にシステムをデバッグしないほうがいいです.一山二虎を許さない道があるのか.(ne cook in the kitchen is enough.)
三、前に何があったの?

$ history

前のサーバで実行したコマンドを確認します.見てみるといつも間違いなく、前に見た誰がログインしたかの情報を加えると、少し役に立つはずです.またadminとしては、自分の権限を利用して他人のプライバシーを侵害しないように注意しましょう.
ここで注意しておくと、HISTTIMEFORMAT環境変数を更新して、これらのコマンドが実行された時間を表示する必要があるかもしれません.そうでなければ、いつ実行されるか分からない命令ばかり見ていると、同じように気が狂います.
四、今実行中のプロセスは何ですか.

$ pstree -a
$ ps aux

これはすべて既存のプロセスを表示します.ps auxの結果は比較的雑然としており,pstree -aの結果は比較的簡単明瞭であり,実行中のプロセスおよび関連ユーザを見ることができる.
五、傍受するネットサービス

$ netstat -ntlp
$ netstat -nulp
$ netstat -nxlp

私は一般的にこの3つのコマンドを別々に実行しています.すべてのサービスが一覧表示されているのを一気に見たくありません.netstat -nalp倒れてもいいです.しかし、私は決してnumericオプションを使いません(私の少しの浅薄な見方:IPアドレスはもっと便利に見えます).
実行中のすべてのサービスを見つけて、実行すべきかどうかを確認します.各リスニングポートを表示します.netstatに表示されるサービスリストのPIDとps auxのプロセスリストは同じです.
サーバ上でJavaやErlangなどのプロセスがいくつも同時に実行されている場合は、PIDごとに各プロセスを見つけることが重要です.
通常、サーバごとに実行されるサービスは少なく、必要に応じてサーバを増やすことをお勧めします.1台のサーバに3、40個の傍受ポートが開いているのを見たら、やはり記録をして、後で暇なときに片付けて、サーバを再編成します.
六、CPUとメモリ

$ free -m
$ uptime
$ top
$ htop

次の点に注意してください.

まだ空きメモリがありますか?サーバはメモリとハードディスクの間でswapを実行していますか?

残りのCPUはありますか?サーバーは何コアですか?CPUコアの負荷が多すぎますか?

サーバの最大の負荷はどこから来ますか?平均負荷はいくらですか?

七、ハードウェア

$ lspci
$ dmidecode
$ ethtool

多くのサーバーが裸の状態です.
RAIDカード(BBU予備バッテリーを持っていますか?)、CPU、空きメモリスロット.これらの状況に基づいて、ハードウェアの問題のソースとパフォーマンスの改善方法を概説することができます.NICは設定されていますか?半二重で動作していますか?速度は10 MBps?TX/RXエラーはありますか?
八、IO性能

$ iostat -kx 2
$ vmstat 2 10
$ mpstat 2 10
$ dstat --top-io --top-bio

これらのコマンドは、バックエンドのパフォーマンスをデバッグするのに役立ちます.

ディスクの使用量を確認します.サーバのハードディスク(HDD)がいっぱいですか.

swap交換モード(si/so)がオンになっていますか?

CPUは誰に占用されますか:システムのプロセス?ユーザープロセス?仮想マシン?

dstatは私の一番のお気に入りです.それを使って誰がIOを行っているかを見ることができます:MySQLはすべてのシステム資源を食べましたか?それともあなたのPHPプロセスですか?

九、マウントポイントとファイルシステム

$ mount
$ cat /etc/fstab
$ vgs
$ pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box */

は全部でどれだけのファイルシステムをマウントしましたか?

サービス専用のファイルシステムはありますか?(例えばMySQL?)

ファイルシステムのマウントオプションは何ですか.noatimeですか.  default ? ファイルシステムが読み取り専用モードに再マウントされましたか?

ディスク容量はまだ残っていますか?

大きなファイルが削除されましたが、空になっていませんか?

ディスク領域に問題がある場合は、パーティションを拡張するスペースがありますか?

十、カーネル、割り込み、ネットワーク

$ sysctl -a | grep ...
$ cat /proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy servers */
$ netstat
$ ss -s

あなたの割り込み要求はCPU処理に均等に割り当てられていますか?それとも、大量のネットワーク割り込み要求やRAID要求でCPUのコアが過負荷になっていますか?

SWAP交換の設定は何ですか?ワークステーションにとってswappinessを60に設定すればいいのですが、サーバにとっては大変です.サーバにSWAP交換をさせないほうがいいです.そうしないと、ディスクの読み書きがSWAPプロセスをロックします.

conntrack_maxは十分に大きく設定されていますか?サーバーのトラフィックに対応できますか?

異なる状態で(TIME_WAIT,…)TCP接続時間の設定はどのようなものですか?

存在するすべての接続を表示するには、netstatが遅いので、ssで全体を見てみましょう.

Linux TCP tuningを見て、ネットワークのパフォーマンスのチューニングのポイントを理解することもできます.

十一、システムログとカーネルメッセージ

$ dmesg
$ less /var/log/messages
$ less /var/log/secure
$ less /var/log/auth

エラーと警告メッセージを表示します.たとえば、接続数が多すぎることによるものが多いのではないでしょうか.

ハードウェアエラーまたはファイルシステムエラーがあるかどうかを確認します.

は、これらのエラー・イベントを、前に発見された疑問点と時間的に比較できるかどうかを分析する.複数のマシンがある場合は、不便そうに見えますが、事前にシステムノートのクラウドログサーバにログを保存し、全文のあいまいな検索をサポートすることができます.

十二、定時任務

$ ls /etc/cron* + cat
$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

タイミングタスクが頻繁に実行されていますか?

非表示のタイミングタスクをコミットしたユーザーはいますか?

障害が発生した場合、バックアップタスクがちょうど実行されていますか?

十三、応用システムログ
この中には分析できるものがたくさんありますが、運維員としてよく研究する暇はないかもしれません.典型的なLAMP(Linux+Apache+Mysql+Perl)アプリケーション環境では、明らかな問題に注目します.

Apache & Nginx; アクセスとエラーログを検索し、5 xxエラーを直接探して、limit_があるかどうかを確認します.zoneエラー.ここで調べてみると、503のエラーはなく、403のエラーしかありません.

をスキップできます

MySQL; mysqlでlogはエラーメッセージを探して、構造が破損しているテーブルがあるかどうか、innodb修復プロセスが実行されているかどうか、disk/index/queryの問題があるかどうかを見ます.

PHP-FPM; php-slowログが設定されている場合は、エラーメッセージ(php,mysql,memcache,...)を直接探し、設定されていない場合は、急いで設定します.

Varnish; varnishlogとvarnishstatでhit/miss比を調べた.エンドユーザーがバックエンドに直接***できるように、構成情報にどのようなルールが漏れているかを見てみましょう.

HA-Proxy; バックエンドの状況はどうですか?健康状態検査は成功しましたか?フロントエンドまたはバックエンドのキューサイズが最大値に達しましたか?

結論
この5分後、以下の状況を明らかにする必要があります.

サーバ上で実行されているのは何ですか?

この障害は、IO/ハードウェア/ネットワークまたはシステム構成(問題のあるコード、システムカーネルチューニング、...)に関連しているように見えます.

この故障にはおなじみの特徴がありますか?たとえば、データベース・インデックスの不適切な使用、またはapacheバックグラウンド・プロセスが多すぎます.

本当の故障源を見つけることもできます.まだ見つかっていなくても、上記の状況を明らかにした後、あなたは今でも深く掘り下げる条件を備えています.頑張りましょう!