前两天我被一篇「不是因为坚强而漂亮，而是因为漂亮而坚强」的文章震撼到了，一个丑女孩（原谅我，文中女孩未减肥前实在够不上漂亮二字），成功瘦到只有原来的一半！因为身材变好，整个人完全不一样了，更自信更乐观更坚强了！这就是颜值不够身材凑的典型！
图注：我大 GiGi 很美，因为身材炒鸡棒更美！郑重声明照片费上文中提到的 MM。
当然今天小编并非要分享本人的瘦身经历，当然小编也没有过减肥的经历（小编近五年维持身高161cm，体重49kg，说不上瘦，但也够不着胖），但是小编却有过其他方面的经历可以分享给大家，同样是对无法克服的缺陷另辟解决蹊径。
接下来小编要聊的是曾遇到的运维那点事儿。
无论我们是运用 24x7 小时网络运行中心( NOC )和记录详尽的进程来实现传统运营过程，还是通过多功能团队和高迭代式性方法来学习 DevOps 模式，我们都面临一个问题，那就是在监控系统、监控告警和我们用来处理运营问题的过程之间沟通不畅的情况日益增多。我们通常会在工单里记录下事件，但是处理工单的员工是否知晓潜在事件下的实时状态？
对于重置密码、更换硬盘或是修复用户手机等帮助中心类任务，这个问题的意义不大。但如今环境复杂，监控系统层层堆栈，要想团队与不断变化的服务问题保持同步确实是不小的挑战。
以我们在运营中常见的典型工作流模式为例。可能存在这样的情况：我们收到的告警可能来自一封邮件、一条短信或者控制面板给出的指示。此时，我们可以通过已定义的流程或特定流程来处理这个事情，比如打开一个工单，直接对这个事件进行分析调查。我们也可以参照说明书、打开终端会话、查看某些图表或是运行特定的诊断工具等任何当时我们能想到的办法。如果我们自己无法解决，可以通过转发功能或者设置的升级策略让更适合的人处理故障。
但是潜在的故障问题会随时爆发，而且我们使用的监控系统各不相同，越来越多相同或者类似故障问题的告警塞爆了我们的收件箱，或是让我们的手机响个不停。不止一个客户反映：当故障已经被确认到解决该故障期间，仍然会不停收到相同告警内容的邮件和短信！这其实是不合理的。
对此，OneAlert 给出了一个既简单粗暴的解决方案。当告警出现时，我们就已经把这些告警收集到一个级别更高的容器中，我们称之为「事件」。一旦你着手解决手头上的某个实际问题，我们认为，既然这些告警都与目前正在处理的问题相关，那就可以把它们全都集中到一个实时的状态页面，作为调查分析和解决过程中最可靠的帮手。可以直接在移动设备上打开，也可以在桌面浏览器中打开。你在解决问题时，会发现告警状态也在不断变化。它可以让原先在分散各处的操作台、控制面板、日志查看软件等资源变得有条理一些。不会再因为告警为解决而不停收到相同告警邮件和短信而烦躁了，这都是变相的压力呀！
事件解决以后，OneAlert 最多能保留一年内发生的所有告警事件。如此庞大的分析功能，对事件分析提供了多大的便利！所有在中断过程中影响到系统的告警都逐个逐条、条理清晰地罗列出来。事件的发展全部呈现在一张大表里面，包括各种不同的告警及其在整个过程中的状态变化。原本，事后为了反思整个过程，需要重新组合排列所有邮件和其他资源（告警事件越多，时间越久，所浪费的整理事件越长），现在完全可以省去这部分的人力和时间。
所有人都可以在同一个云告警平台 OneAlert 操作，可以看到整个处理过程，包括处理人、处理方式、处理内容、处理结果等，所有人的认知都随时保持同步，完全排除因沟通不畅导致的故障无法顺利和按时解决的问题。
非常不错吧？日常生活中，人与人之间的沟通必不可缺，但是对于运维，特别是需要处理非常环境庞杂的问题，有些流程上能 cut 沟通，如果能够通过同一个平台简单直观的同步达成全体人员的共识，我们何乐而不为？更何况，这个平台还能对你的告警进行事件聚合，免受告警风暴的影响，告诉我，你真的想错过么？
想试试 OneAlert 么？
快点行动起来吧，还是免费的哟！与 OneAlert 一起携手，从头到尾改善你的事件管理吧！更多内容可参看OneAlert 官网 。
参考文献：Get everyone on the same page... Literally
本文转自 OneAPM 官方博客