运维质量事件（运维服务质量管理）

本篇文章给大家谈谈运维质量事件，以及运维服务质量管理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享运维质量事件的知识，其中也会对运维服务质量管理进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、出现运维事故后，你会怎么办？
• 2、甲方电力运维单位工作的要求
• 3、运维告警等级详解

出现运维事故后，你会怎么办？

有一次和朋友聊天，他说他们有一次部署出事了，影响还挺大，那次事故后，他们公司对于部署流程增加了更多的审批。

当朋友说完前半句时，我已经猜到下半句，那是很多公司或个人会做出的反应。至于为什么会做出这样的反应，我也不知道。

我问：为什么那次部署会“出事”？

他说：当时部署的人忘记了那台机器上有一条 Iptable 规则，导致了事故。

我就在想，如果有人审批，那次事故就不会发生吗？审批的人就知道那台机器上有一条规则导致事故的发生？然后驳回这次部署吗？连一线的开发和运维都忘记了的 Iptable 规则，“高高在上的审批领导”就更不知道了。

题外话：增加审批流程并不能避免这次事故，只不过当出现事故时，可以更好的定责。然而我又好奇了，这种“审批”是为了解决问题，解决什么问题？，还是为了逃避责任？谁逃避了责任？谁又有责任？

对于这类问题，我心里已经有数了，但想知道这位朋友的回答，就接着问：那么怎么杜绝这类问题呢？

这位朋友说的做法，我之前待的一个团队的做法也差不多：会有一个页面专门记录下每次部署的步骤，步骤由开发人员写，然后由运维人员执行。只是我不知道他们会不会回顾之前所有针对这台机器的部署步骤。

这个团队里有某某大型互联网公司来的架构师和某财务软件公司来的运维，所以，我不负责地推测，我们这个行业很多公司对于配置的管理还没有达到足够的重视，也没有正确的看待。

我笑了，接着问朋友：那我要知道当前机器的“最终状态”，是不是要找出所有部署记录，还要过滤出对这次部署有影响的每一个细节？比如那条 Iptable 规则。

接下来的对话细节已经记不清，也不重要了。重要的是找出针对这类运维事故根本原因及解决办法。

我个人认为这类问题的根本原因在于：

以上只是我个人认为的，不一定正确，欢迎各位读者讨论。

那如何杜绝这类问题呢？

这两个原因可以看作一个，也可以看作两个。但方法都是一样的：

脚本式的配置管理是这样的：

而声明式的配置管理是这样的：

声明式的配置里写的是当前环境的“状态”，语意上，声明式的配置不论你执行多少次，你得到最终的“状态”就是你所声明的，这也就实现了《持续交付》里说的：

这样，你就不用在第1000次部署时，根据前999次部署脚本找出对这一次部署有影响的细节了。

具体实践时，我发现 Ansible 就能很好的做到这点。

将这些配置版本化的好处，就不需要重点说明了。

具体一点的说就是所有环境都使用相同的声明配置，具体到不同环境时，使用变量替换。这样就可以保证所有环境的一致性了。

具体实践方法，还需要根据所在团队调整。你也可以通过本文附录里链接，参考其他人是如何实践的。

关于配置管理

多环境配置管理

甲方电力运维单位工作的要求

1、严格执行合同约定运维质量事件的相关标准、规程、规范及技术要求运维质量事件，做到工程实施各分项工作、质量及技术指标符合验收标准。
2、项目部负责按工程要求编制技术方案、施工方案、作业指导书等文件运维质量事件，经工程部经理审核批准后执行运维质量事件，实施规范化、标准化作业。
3、做好工程材料、设备检查验收工作，严禁不合格品进入工作现场。
4、严格质量检查验收工作，责任到人，严格执行‘谁签字谁负责”
5、严格执行公司工程资料管理规定，认真按照项目验收要求和项目管理要求，建立健全运维记录、施工档案资料等。
6、发生质量事件，按项目责任书或工作失误的相关规定对责任人进行考核。

运维告警等级详解

互联网时代 IT 相关的衍生产品有很多，监控工具为其中的佼佼者。很多监控工具对于确保网站和应用的平稳运行做了非常多的工作，但是，对于告警产生到通知用户的过程，还有很大的改进空间。

在合理评估告警严重程度的基础上，确保通知合适的运维汪，对于快速有效解决事件至关重要。但是我们对告警等级的重要性以及如何设置告警等级来提高团队效率，还缺少必要的认识。针对该问题，以下几条快速指南可以供大家参考。

什么是告警等级？有什么重要性？

简单来说，告警等级是表征事件严重性的指标之一，取决于事件对用户体验以及网站或应用整体性能造成的负面影响的大小。

例如，导致网站崩溃的事件，被认为负面影响极大，告警等级也就较高；而一个Ping的问题有时不会很明显，被认为负面影响略小，告警等级也就较低。

告警等级的重要性体现在以下方面：

有助于减少和控制告警噪声的数量。

使得错误处理流程更为顺畅。

使你解决问题更有效率。

总而言之，根据告警等级不同，可以优先处理重要事件，避免干扰到不在职责范围内的无关人员。

怎样创建合适的团队告警等级规则？

确定告警等级的重要性，相信大家已经了解了，但如何创建一个适合整个团队事件严重程度的评估方法，是监控工具开发人员的棘手问题。

一般来说，评估告警等级过程需考虑以下3个方面：

1.严重性等级结构

2.团队结构

3.通信结构

1）严重性等级结构

严重性等级的主要目的是确保合适的人员能够知道问题，并按照严重程度来处理问题。一般来说，设置严重程度等级结构的最简单方法是根据商业价值来确定网站或应用的最关键部分。并且在团队中，并没有所谓的正确或错误的方式来判定严重性等级。要知道，重要的是了解团队如何划分具体的事件，并确保每个人都达成共识。

2）团队结构

清晰地认识团队结构并对告警进行有序分派，将提高整个团队的执行效率。为了更有序和有效的分派告警，我们应该注意几个问题：

告警处理需要涉及哪些人？

处理事件时，每个人的责任是什么？

告警要求在哪个环节通知哪些人？

3）通信结构

如果你不知道告警在团队结构内应该如何通信，那么建立通信结构将是创建严重性等级过程中最为困难的一环。

你可以这样考虑：

严重性等级结构：这个问题有多严重？

团队结构：这是谁的责任？

通信结构：如果问题发生，如何以及何时联系团队成员？

创建通信结构能将不同事件与团队中的不同角色联系起来，并根据时间紧迫度与错误频率添加更明确的操作。这样，可以确保通过恰当的渠道联系到合适的人员，且符合当前的情况。如果一个响应者不在线上，可通过告警升级机制确保团队中的其他成员得到通知。

根据团队结构，选择合适的通知渠道与阈值配置，意味着问题解决能更加高效，且不会牵涉到无关人员。
RIIL是国内领先的IT综合管理解决方案，通过IT资源综合监控、运维流程管理、3D数据中心管理三大模块帮助客户实现IT部门人财物的全面管理，提升IT服务质量以及运维管理绩效 关于运维质量事件和运维服务质量管理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维质量事件的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于运维服务质量管理、运维质量事件的信息别忘了在本站进行查找喔。