運用・保守、トラブルシューティングのアイデア

1、一般的な方法：

1）最初の印象に影響を与え、症状や問題を判断
運用・保守要員が最初にしなければならない、治療前の失敗には症状を知って、症状直接アプリケーションシステムの全体的な機能がいくつかを持っているために必要な操作や保守担当者に応じて、危機管理計画を策定するために失敗を決定親しみやすさ。障害を決定するために早期の運用・保守担当者を案内するために、障害の現象を確認した後。

2）緊急リカバリ
操作および保守は、システムの可用性の最も基本的な指標である、緊急復旧の適時性があるシステムの可用性重要な指標。
裁判官は、上記の症状と効果を持っているしたら、緊急の故障のような、多くのがあり、障害の緊急手術を開発することができます。

;サービスの性能劣化や異常な全体的に、サービスを再起動するとみなすことができる
アプリケーションは、変更をした、変更が戻ってカットする必要があるかどうかを検討し、
リソース不足、緊急時の拡大を検討し、
アプリケーションのパフォーマンスの問題、アプリケーションパラメータ、ロギングパラメータを調整することを検討して、
データベースがビジー状態である、ことができますデータベーススナップショット分析、最適化SQLによる検討、
機能設計エラーのアプリケーションは、あなたが緊急シャットオフ機能メニューを考えることができ、
たくさんあります......

また、追加する必要があり、緊急の障害が発生する前に、条件の場合には、あなたがCOREファイルやデータベースのスナップショットファイルをつかむことができ、そのような決済処理以前のように、現在のシステムのシーンを保存する必要があります。

3）高速な故障個所
それが再現可能かどうか、偶発であるかどうか
の症状が再現できるならば、それは問題を迅速に解決することが重要である、あなたはいつもの方法または私たちは、問題の原因を特定するのに役立つツールを説明を再現することができ、かつ再現することができます障害は異常なサービスが作業を変更することに起因する問題であってもよいことが多いです。障害が散発的であるならば、システムは常に原因を突き止めるするかどうかを決定するためにサイトの障害時に十分な情報を持っているかどうかに応じて、非常に小さな発生確率、調査はより困難があります。

是否进行过相关变更
大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

是否可缩小范围
一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

关联方配合分析问题
与第（3）点避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。

是否有足够的日志
定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。

是否有core或dump等文件
故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如CORE\DUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。

上述是一般性的故障常见的方法，在重大故障或多方处理的故障出现时，往往小范围的排查不利于快速解决，需要启动紧急处理的流程，建议可以考虑以下沟通：

召集相关人员
描述故障现状
说明正常应用逻辑流程
陈述变更
排查进展，展示信息
领导决策

2. 完善监控

1）从监控可视化上完善
完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率。

2）从监控面上完善
监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在应用软件类的监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、应用层的监控。全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。

3）从监控告警上完善
完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。

4)从监控分析上完善
完善的监控策略不仅需要有实时的数据告警，也要有汇总数据的分析告警,实时数据分析的告警的重要性不用多说，对于汇总分析的数据则能发现潜在风险，同时也为分析疑难杂症提供帮忙。

5)从监控主动性上完善
监控不仅仅是报警，它还可以做得更多，只要我们想办法赋予它主动解决事件的规则，它便有为管理员处理故障的能力。

3、应急方案

提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题：

1）应急方案缺乏持续维护，缺乏演练，信息不及时、不准确；

2）应急方案过于追求大而全，导致不利于阅读与使用；

3）应急方案形式大于实际使用效果，方案针对性不强；

4）只关注应急方案的内容，但没有关注运维人员对方案的理解；

针对上述常见问题，应急方案需要做到以下几点：
1）内容精简
很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。以下是应用系统应急方案应该有的内容：

（1）系统级：
能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。

（2）服务级：
能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。

（3）应用级：
能知道如何查到某应用出现了问题，是大面积、局部，还是偶发性问题，能用数据说明应用影响的情况，能定位到应用报错的信息。这里最常用的方法就是数据库查询或工具的使用。知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，业务的时间要求及应急措施。

（4）辅助工具的使用：
有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。

（5）沟通方案：
沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。

（6）其它：
上述5点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作。

2）应急方案是一项持续的工作
有了应急方案，如何让运维人员持续去更新是难点。要解决这个难点，需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。应急方案最终可以归档到知识库。

3）关注运维人员对应用关键信息的认识
前两点关注了手册，最后一点有必要关注使用这个手册的人。有些运维人员认为应用运维人员没有能力去把应用系统本身的内容了解得很透彻，所以应用运维人员在故障处理过程中的地位很尴尬，运维人员掌握操作权，但却不知道应该操作什么。

对此，应用运维人员不需要掌握应用系统的业务功能，但就对应用系统本身来讲应用运维人员需要具备以下最基本的能力：

（1）知道应用系统这个是干什么的，基本的业务是什么；
（2）知道应用架构部署、上下游系统逻辑关系；
（3）知道应用下的服务的作用、端口、服务级的应急处理，日志等数据信息如何找到并简单定位。
（4）知道应用系统重要的时间点及任务，比如定时任务的时间点以及如何判断这些任务是否正确
（5）知道最重要的业务流程；
（6）知道常见数据库表结构，并能使用。

参考：

https://iangilham.com/2016/12/08/core-dump-from-centos-7.html

：今日は技術的リーダーシップ、経営管理、システムアーキテクチャ設計と評価、チーム管理、プロジェクト管理、製品管理、チーム便利なリファレンスを構築することを望んで、まずここに来て、あなたが記事に興味がある可能性があり
とリーダーシップを共有するためにリーンIT組織
リーダーシップどのように人々は良いチームを導く
建物はの暴行小さなチームスタートアップと
の国際的な環境の進化の下でシステムアーキテクチャを
マイクロサービスアーキテクチャ設計
アーキテクチャの進化ビデオ放送プラットフォームシステム
マイクロサービスとドッカー紹介
ドッカーとCI継続的インテグレーション/ CDの
インターネットの電気事業カートアーキテクチャはケース進化する
インターネットを下のメッセージキューアーキテクチャのビジネスシナリオ
インターネットの進化と効率的なR＆Dチーム管理1つ
のメッセージングシステムアーキテクチャの進化
インターネットアーキテクチャの進化一つの電気供給業者検索
企業情報技術とソフトウェアエンジニアリングの神話
エンタープライズプロジェクト管理が記述する
成功したソフトウェアプロジェクトの要素
対人コミュニケーションスタイルのプレゼンテーションを
学習組織や企業の
技術革新の文化や階層
組織の目標と個人的な目標のは、
採用管理や起動
才能企業環境企業文化や
企業文化、チームの文化と知識の共有
、高性能チームビルディング
プロジェクト管理コミュニケーション計画
高構築するために効果的な研究開発とオートメーション・運用・保守大型電気プロバイダクラウドプラットフォームの練習のインターネット・データベース・スキーマのデザインのアイデア ITインフラストラクチャの計画（ネットワークシステムの計画）解析処理のカスタマーケータリング業界ソリューション食品・飲料業界のソリューション戦略の策定と実施プロセスの購入

設計プロセスの食品産業ソリューション事業のサプライチェーン調査チェックリスト必要リアルタイム計測システムの進化にエンタープライズアプリケーションのパフォーマンスを

より多くのソフトウェア設計とアーキテクチャ、ITシステム、企業の情報技術、経営陣を学びたいのであれば、私のマイクロチャネルのサブスクリプション番号に注意してください。

著者：ペター劉
出典：http://www.cnblogs.com/wintersun/
この記事では、著者とブログパークの合計に属し転載を歓迎しますが、この節で宣言され、著者の同意なしに保持され、元の記事のページの見かけ上の位置を与えられなければなりません接続、法的責任を追及する権利そう。記事はまた、-Petter劉ブログでブログを独立に掲載しました。