1.概要
回線障害が通常の人気話すがこれです、大規模なオンラインサービスの可用性の問題や事象の影響を指し：アウト「穴」に、「ピット」は断層線です！「ピット上のステップ」、「ジャンプピット」、「穴を埋める」、「ピットを避ける」：回線障害を処理することは鮮やかとして表現することができます。
ライン治療の失敗は、それが技術者/技術チームの応答性、意思決定能力、判断能力、組織力のテストで、ライブだけの技術ではありません。フェイス突然の生産障害、すぐに問題を特定する必要性、解決策を見つけ、迅速な導入ソリューションは簡単なことではありません。この記事では、以下が含まれます。ターゲットラインのトラブルシューティング、アイデア、手順、インフラストラクチャを。
この記事は、通常のトラブルシューティングの経験の生産と加工に基づいて表面的な方法論のいくつかをまとめ、議論し、一緒に改善するために、探求する歓迎されています。
2.ターゲットラインのトラブルシューティング
どんな動物が穴に落ちたら、賢明でなければなりません：ジャンプピット - >いっぱいピット - 次のように>回避ピット、プロセスのオンラインすぎて、トラブルシューティング、ハイからロー優先対象に、オンライントラブルシューティングがあります：
ジャンプのピット
「ジャンプピット」 - 急速な回復オンラインサービス、またはオンラインサービスへの影響を最小限に抑えることになります。
オンラインサービスの可用性は、同社の業績に影響を与え、クライアントの利益を決定します。オンライン環境は、同社に/経済的利益の損失をチーム、サービス利用者へのできない、利用できなくなると、より深刻な会社を与える/チームは悪い評判をもたらします。そのため、同社は、チームや部署であるKPIをオンライン環境の全般的な安定性と信頼性の要件を発生させます。このため、障害が生産に遭遇した後の最初の優先順位は：最小限にオンラインサービスに影響を与えるための方法を見つける必要がありますが、完全にオンラインサービスを回復していない場合でも、生産サービスを復元します。
満たされたピット
根本的に問題を解決し、問題の原因を見つけるために - 「穴を埋めます」。
失われたユーザー/会社/チームのインパクトをもたらすを最大化するためにオンラインサービスを、復元した後、我々は徹底的に問題が、根本的な問題を解決するために、障害の根本的な原因把握を調査する必要があります。通常の状況下では、と「ジャンプピット」「の穴を埋める」を完了させるために、やって同期されている「穴を埋めること」も "ジャンプピットの成功を意味するが、また、再起動など、いくつかの緊急事態における特別な「ジャンプピット」メソッドを、持っていますその上のサービス、またはサービス低下/ヒューズと、それはゆっくりと「穴を埋める」、「穴を埋める」の終了時に、実際にはありませんが、型破りな手段「ジャンプピット」を取ることが最初。
ピットを避けます
「ピットを避けるために、」 - 隠された危険性を排除するために最優先。
根本的な原因を見つけ、問題を解決した後、我々はここから類推、順番によって学ぶ必要があり、このトラブルシューティングの過程で考え、これらの分野での弱点があるのですか？これらの手順/ルール/システムを最適化する必要がありますか？このような問題は、他のシステムやチーム内に存在するかどうか？常にこのような反射と自己批判、オンラインインシデント報告書、およびを通じてプロセスを改善し、ステッピングピットを避けるために、為替の経験に再びチームであり、一緒に改善します。
3.オンライントラブルシューティングのアイデア
「塗りつぶし - 重点目標と目的ベースのオンライントラブルシューティング、最初のラインのトラブルシューティングの目標は、オンラインサービスを復元したり、オンラインサービスへの影響を軽減することであるが、重要な点は、その単語迅速、「ジャンプピット」であります「ピットを避ける「ために、再び要約、」ピット。このように、オンラインのトラブルシューティングの手順は、に分けることができます。
- 障害が見つかりました。
- フォルトの場所
- トラブルシューティング
- 障害バック
これは最初の3つのステップ「ジャンプピットの行動のうち、ステップバック「穴を埋める」と「ピットを避ける」が含まれています。
上記の手順は、上から下へのない平均ため、それは推奨されないカオス足場の場合には、やって平行それは通常の断層線、運用・保守、開発、テスト、製品の各文字の意志の後に緊急フォルトハンドラを起動しますので、関与、この時分割ダウンし、やって平行、迅速なトラブルシューティング、リカバリー・サービスのためのサマリメッセージ、メイク判断を、保ちます。このアイデアは/効率の向上を目的とした、デザインに参加し、オペレーティングシステムのフォークに似ています。
すぐに故障の原因を見つけることができないこと、決定的なスキップされた障害のために必要な最小限にそのオンラインサービスを確保するためのサービス低下、サーバーの拡張や他の手段の使用などのリンク、直接のトラブルシューティングを、位置及び制御。私たちはゆっくりと根本的に問題を解決するため、障害を見つけるために、過去の後にオンラインサービスのサポート」まで待ちます。
ここでは詳細にこれらの4つのステップがあります。
3.1障害FOUND
通常ラインは、問題の深刻さを順次増加し、上から下へ順に、いくつかの経路により、開発者/保守員の手に転送することができるフォールト。
- アクティブディスカバリは-開発や出荷不注意本番環境の間次元ビューすることができるエラーログ、または項目を監視ルーチン検査を、異常現象のいくつかを見る、見つから障害;
- 警報システム監視-通常含まれ、CPU、メモリ、IO、TCP接続、ディスク、スレッドの数を、GC、コネクション・プーリングやその他の異常・サーバは、サーバが異常な表示されることがありますが、ビジネスは影響力の大きな領域なかったです。
- ビジネス監視アラーム-などの増加、ユーザーのログインの失敗率など、注文の量を増やすには積み上げ、それはシステムは、ビジネス・プロセスに影響を与える、非常に深刻な異常を有することを意味します。
- 遡及関連したシステム障害 -システムの上流またはメールシステム/電話トレーサビリティの下流のトラブルシューティング、およびシステムが関係を有していてもよい、と状況は非常に悪いとなっている、すぐに見つけることが必要です。
- プロダクションイベント・レポート -効果は通常、技術スタッフの手に、顧客サービスのスタッフに、ユーザーからユーザーに配信した後、渡された異常なサービスによって引き起こされるので、生産イベントのレポートと、この時間は、の深刻さになっている、いくつかの遅延が発生します最高の技術者は、圧力がリーダーシップに焦点を当てますので、お問い合わせのプロダクトマネージャーを圧力を高め、顧客の担当者によって引き起こされる不安を促します。
これは断層線ではないことを確認するために、あなたが最初に必要なので、ルートの情報は、断層線の上にちょうど看板、必ずしも大規模な断層線に発生していないを渡しますか？ほんの一例生産上の問題ですか？そして、システムが関係を持っているかどうか？一般的に言えば：「アラームのモニタリングシステム」と「業務監視アラームの場合」、システムのほとんどと関連していると断層線であってもよく、および「アクティブ発見」との生産事件が報告されたあなたが審査を行う必要があります'これは、イベントや大規模な断層線またはトレースログ情報やユーザー固有の問題が遡及的に決定するかどうかの定期的な問題を報告するには、いくつかの方法に従って評価することができます。「として関連トレーサビリティシステム障害」の場合、最初のパニック、マクロが通常のサービスにシステムを起動するために決定されるログの上流側又は下流側に設けられている場合、サーバは、サービスが決定されているか否かを監視警報を一般的なアラーム監視を確認することができシステムの故障かどうかを決定するために、ログを追跡します。
サービスの監視警報、報告されたインシデント、問題の再発する、サーバ監視の数：だから、いくつかの兆候の断層線を取得した後、ルートが断層線であるかどうかによって判断することができます。これらの経路は、並列、フレキシブル組み合わせで行うことができ、時々決定することができるようにするための手段は、時々判断するために複数の手段を組み合わせる必要があります。
3.2故障箇所
断層線であると判断したら、我々はすぐに右の薬、迅速なトラブルシューティングを処方するためには、問題の原因を見つけるために、障害点の位置を特定する必要があります。
オンライン情報を取得するために、ポイントの疑い、見つけるために、より多くの情報、検証推論、必要な時間を得る：循環プロセス、基本的な考え方故障箇所は、一定の「 - 仮定 - - 検証の試行情報の収集」です可能性の検証措置、実施事業にまたはテスト環境試験、性能試験の再現性に再現するために制御しよう。
あるかもしれない疑いのポイントは以下のとおりです。
- 新しいリリースには、問題を抱えています
- 潜在的なプログラムのバグは、このようなトラフィック急増の場合のように、励起され、並行処理のバグが励起します
- ビジネスボリュームサージ
- などイベント羊毛ブラシパーティの統合、中などに襲わ
- そのようなアップグレードのHttpClient上流システム後など上流のサービスコール異常は、短い接続長に接続されています。
- 異常下流サービス、下流サービスのダウンタイム
- ネットワークの問題
- などフルディスク、メモリ、などのサーバの障害は、鳴り
- アプリケーションの障害
- データベース障害
この目的のために、情報があなたの疑惑ポイントをサポートするために、以下の側面を通じて収集することができます。
- 最近、例新バージョンをリリース
- サービスの異常/エラー・ログ
- インフレがある場合は、このサービスの変化の量を呼び出し？
- 衰退があるかどうか、サービスのスループット？
- 遅延サービス、突然の増加があるかどうか？
- TCPサーバは、CLOSE_WAITの大量の存在を状況にリンク？
- CPUサーバの使用率、突然のサージか？
- ディスクサーバーのディスク容量は、すでに使用されていますか？
- サーバーのメモリ、メモリが鳴りますか？
- かどうかは、データベースのストレージがハングアップ？
多くの障害は、単一の原因によるものではなく、複数の条件が満たされた場合にのみ、そのため、必要性がより多くの情報を収集するために表示され、包括的な情報、疑問点、迅速な推論と検証を得るために、最終的には、ナビゲートし、問題を発見しました故障。このプロセスは、すべての人の努力、各チェックポイントに平行で、かつ高速なフィードバック情報の収集することができます。
多くの組み合わせ、唯一の明白な故障箇所のシーンリストとして、より要約する必要があります。
- 最新バージョンをリリースし、第1主に新バージョンによって引き起こされる問題に、解放後の時間を登場トラブルがリリースされ、おそらくバグ、それは問題を展開することができ、
- 新しいリリースでなく、ビジネスのトラフィックは、サービスの待ち時間が増加を急増し、スループットが増加し、その後減少し、最後の直接のサービスが利用できない場合、考えられる原因は次のとおりです：トラフィックスパイク/攻撃/上流のサービス例外コール。
- おそらく増加したビジネストラフィックに新しいリリース、サービス障害の一部、増加したサービス・エラー・レート、ビジネストラフィックの増加は、潜在的な並行処理のバグを刺激しない、またはIOボトルネックが登場します。
- ビジネス訪問は増加しますが、減少した待ち時間のサービスを、減少し、スループット、エラーレートがサービスを増加し、サーバのTCP CLOSE_WAITの増加、今回の必要性は疑問下流のサービスが異常である頼ることはなかったです。
- ビジネスの訪問は、データベースログ間違っ多数を利用できないサービスの広い範囲を増加させなかった、それが発生する可能性があり、データベースの問題、またはデータベース接続プールの問題のアプリケーションことは明らかです。
少数を示すために、必要が徐々に蓄積します。以下は、上記の説明の概要です。
故障定位的初期，一般会先通过邮件+电话的方式进行沟通，如果几分钟之后事态变糟糕，且没有眉目，则需要紧急启动会议形式的联合排障，所有相关人员需要放下手头事情，集中到一个特定会议室进行联合排障。这样的好处也在于能够迅速共享信息，快速做出决策。联合排障人员通常会包括：开发、运维、测试、产品，主力应当是开发和运维，测试和产品需要帮忙快速确认一些东西，如复现问题，或者确认业务逻辑等。
从上面可以看到，故障定位过程中，追求‘快速’二字，为此多项事情是并行去做的。为了避免出现群龙无首的慌乱局面，需要有一个主心骨坐镇，把握排障的方向并最终做出决策，这个人是master，需要冷静沉着，且要能调度尽可能多的资源，所以技术leader或者运维leader会比较合适。这个类似于分布式系统的设计思路。
另外，在故障定位过程中，获得的线上一线信息需要通过某种形式记录下来，邮件往来是一种比较好的方式，在完成通信和信息共享的基础上，也无形中保留了现场。其他的信息包括：error log，dump文件，服务器各个指标的状态值等等。
3.3 故障排除
一旦定位到故障原因，对症下药地排除故障就不是什么难事了，具体的措施可以参考下图中的总结：
这里需要特别指出一个特别的场景：无法定位故障的情况下如何迅速排除故障。
很多时候无法及时找到故障原因，必须直接进入故障排除，这时候的思路就在于：尽最大可能降低线上服务影响了。可以采用的手段有如下几项:
- 服务降级——定位到某些服务有异常，但不清楚异常出现的原因，直接将这些服务降级，确保其他服务不受影响；
- 服务紧急扩容——无法定位到是哪些服务造成的，服务器资源彪升，扛不住压力时，紧急扩容服务器；比如恶意攻击、营销活动，秒杀等场景带来的突发情况；
- 回退版本——有新版本发布，但是不能迅速确定是否和新版本有关系，先做版本回退，确保线上服务回到上一个稳定版本。
还是那句话，故障排除的原则是：确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。
3.4 故障回溯
故障回溯的目的是在故障排除后，冷静地回溯整个线上故障的发现/定位/排除过程，找出流程中/架构中/制度中的缺陷，并将该缺陷消灭掉，同时推而广之到其他系统。在‘跳坑’--‘填坑’之后，我们需要通过故障回溯的过程达到‘避坑’的效果，即要保证自己能‘避坑’，也保证团队/公司能够避开类似的坑。
故障回溯的过程，因人因团队而异，最重要的是要有严肃的‘形式’和最终的产出物。之所以提到严肃的‘形式’，是因为线上故障无小事，一定要让大家牢记在心。
至于如何达到‘严肃’，可以参考如下形式：
- 可以和kpi挂钩。慎用，可能会伤害到技术人员的心，造成‘懒政’现象——“多干多出事，少干少出事”出现；
- 可以实施追责制度。同上；
- 还可以进行邮件或者会议形式的讨论，广而告之。
总之，故障回溯的最终的目标不是为了追责，更重要的是让大家长记性，避免后续再次踩坑，而且线上故障报告的产出物一定要有，一方面是经验的积累，便于分享，另一方面也让当事人撸清楚事件过程，吃一堑长一智。
可以参考的一个流程如下：
4.线上故障处理的‘后勤保障’
前面谈了线上故障处理的目标、思路和步骤，回过头来看下，要快速准确地定位和排除线上故障，需要很多基础设施支撑，它们是线上故障处理的‘后勤保障’。结合上面的内容归纳总结如下：
完善的监控/告警体系
通过告警，能让我们迅速知道自己的服务出了问题，通过监控可以从时间维度进行对比分析，找到可疑点，进而定位故障。
监控通常分为：
- 服务器监控——针对操作系统资源使用情况(比如cpu使用率、内容使用率、磁盘空间、io、network等)，容器健康程度（内存使用情况、线程数、GC情况等），application健康程度的（服务的可访问性等）;
- 服务监控——包括吞吐量、时延等，这些指标至少包括：最大值、平均值，通过这些指标可以判断单个服务的变化情况和健康程度；
- 业务监控——包括访问量、错误率等，一个业务场景往往会包含多个服务调用，因此通过业务监控，可以发现一些关联问题。
告警方面，需要根据实际情况和业务场景进行阈值设定，告警阈值的设定是一个动态调整的过程。
监控系统最基本的需要保证：按照时间序列进行统计、对比。
完善的日志trace体系
在线上故障处理过程中，日志尤其重要，通过日志能够定位到问题或者bug细节。在分布式架构的系统中，多实例的部署导致日志分散在多台机器上，靠人肉查看耗时费力，效率低下；另一方面，业务发展壮大后，业务系统越来越多，系统间依赖越来越多，各个业务系统的日志需要通过唯一的标识串联起来，否则会出现信息断层的问题，日志变得无用。所以完善的日志trace系统非常必要。
日志trace体系的几个关键点：
- 有唯一的标识串联上下游系统日志
- 能自动收集分布式应用日志
- 日志收集时延不能超过10分钟（具体时间试实际情况而定，如果时延太长，日志没有多大意义）
- 支持多种形式的查询/过滤/统计等
- 可以看到时间序列上的变化趋势
推荐使用开源的日志架构：logstash+elasticsearch+kibana。
完善的故障处理机制
线上故障处理的要点在于快速，所以需要有完善便捷的事件流转机制和故障处理机制来保证：生产事件能快速推送到相关责任人进行联合排除，保证事件排查过程中快速共享信息，快速完成决策。
对于事件上报，一般的公司会有专用的通道给到一线客服人员，客户人员填报工单，上报事件，关键点在于事件处理中担任‘路由’角色的人员，他需要对业务系统比较熟悉，对于上报的问题能快速确定相关的业务系统和负责人，并通知到对方，这个角色既要熟知业务，也要熟知系统架构和组织架构，这个角色一般会交由专门人员处理，称之为‘二线’人员，或者由运维人员兼职。
排查生产事件/故障时，推荐进行集中版本，便于快速共享信息，同时需要有一个master，以便把握大的方向，并快速完成决策。
5.总结
以上，对线上故障处理的目标、思路、步骤及基础设施进行了讨论，先总结如下：
- 线上排障的第一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，需要总结以便‘避坑’。
- 一切的流程或者手段都是为‘快速’二字服务的，所以线上故障是最高优先级的任务，任何人需要第一时间予以响应；同时，尽早地反馈故障问题，尽早地集结各个角色，群策群力地进行排障值得提倡；这个过程中，需要有一位有‘威望’的master坐镇，主持大局；在保证有序推进的情况下，尽可能地并行地收集信息，进行尝试。这个有点分布式架构的味道了，master坐镇，slave并行干活，提高效率。
- 必须要有一个‘严肃’的形式让当事人及旁观者‘吃一堑长一智’，线上故障处理报告是必须的产出物。
- 为了更加高效的处理线上故障，需要有完善的基础设施支撑：监控/告警体系、日志trace体系、事件流转机制。
对于线上排障的流程整理了一个大图，如下：
