Operation and maintenance troubleshooting ideas

1, the common method:

1) determine the symptoms and problems that affect initial impression
prior to treatment failure, operation and maintenance personnel must first know Symptom , Symptom directly determine the failure to develop contingency plans, depending on the operation and maintenance personnel required for the overall functionality of the application system has some Familiarity. After confirming the fault phenomena in order to guide the operation and maintenance personnel early to determine faults.

2) Emergency recovery
operation and maintenance is the most basic indicators of system availability, timeliness of emergency restoration is the system availability key indicators.
After the judge has the above symptoms and effects, you can develop a fault emergency operation, failure of emergency there are many, such as:

Overall service performance degradation or abnormal, can be considered restart the service;
the application did change, consider whether changes need to cut back;
insufficient resources, consider emergency expansion;
application performance problems, consider adjusting the application parameters, logging parameters;
the database is busy, you can consideration by the database snapshot analysis, optimization SQL;
application of functional design error, you can consider emergency shut-off function menu;
there are a lot ......

In addition, the need to add is, before the failure of emergency, in the case of conditions need to preserve the current system scene, such as before the settlement process, you can grab a CORE file or database snapshot files.

3) fast fault location
whether it is accidental, whether reproducible
if the symptom can reproduce, it is important to quickly solve the problem, you can reproduce explanation always a way or a tool to help us locate the cause of the problem, and can reproduce the failure is often abnormal service may be a problem, due to changing work. If the fault is sporadic, there is a very small probability of occurrence, the investigation more difficult, depending on whether the system has sufficient information during site failures to decide whether to always locate the cause.

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

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

关联方配合分析问题
与第（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

Today come here first, hoping to technology leadership, business management, system architecture design and evaluation, team management, project management, product management, team building a useful reference, you may be interested in the article:
Lean IT organizations to share leadership with
leadership how people lead the good team
building startups assault small team of
system architecture under international environmental evolution of
micro-services architecture design
video broadcast platform system architecture evolution
micro services and Docker introduction
Docker and CI continuous integration / CD
internet electric business cart architectures evolve case
the internet message queue architecture business scenarios under
Internet evolution and efficient R & D team management one
messaging system architecture evolution of
the Internet architecture evolution one electricity supplier search
enterprise information technology and software engineering myth
enterprise project management describes
the elements of a successful software project
interpersonal communication style presentation a
learning organization and enterprise
innovation culture and hierarchy
of organizational goals and personal goals
startups recruitment management and
talent corporate environment corporate culture and
corporate culture, team culture and knowledge sharing
high-performance team-building
project management communication plan
to build high Effective research and development and automation operation and maintenance of a large electricity provider cloud platform practice Internet database schema design ideas IT infrastructure planning a (network system planning) Customer catering industry solutions for the analysis process purchases of food and beverage industry solutions strategy formulation and implementation process

Food industry solutions business of the design process supply chain research needs CheckList performance of enterprise applications in real-time measurement system evolution

If want to learn more software design and architecture, systems IT, enterprise information technology, management team, please pay attention to my micro-channel subscription number:

Author: Petter Liu
Source: http://www.cnblogs.com/wintersun/
This article belongs to the author and blog Park total, welcome to reprint, but without the author's consent declared by this section must be retained, and given the apparent position of the original article page connection, otherwise the right to pursue legal responsibilities. The article also posted on my blog independence in -Petter Liu Blog.