一个运维老兵自撸的告白

笔者从事运营商行业开发运营工作近20年，历经开发、运维、产品等工作岗位。从项目需求分析到开发代码交付，再到应用上线后的运营维护，均全流程，无死角的撸了一遍。

这其中，运维岗待的时间最长。运维人员的苦逼日常，闭上眼睛至今仍像小电影样的浮现在我的面前。

那些运维的日子里，每日不是在加班处理业务投诉工单，就是连续通宵故障处理，没完没了的割接、演练、上线中度过。活生生把我从一个青春活力的白胖子，熬成了一个苦大仇深的黑胖子。日渐稀少的发量是我心中永远的痛……

运维工作除了保障日常系统稳定运行之外，这些因新业务上线带来的问题单都是需要人一个一个的解决的，每一个问题的解决都是运维人通宵达旦的付出。

回想当年维护的填坑岁月，苦逼场景还是清晰浮现眼前。在那个缺少工具平台的年代，你工作的年限，所谓的经验，只能是你处理问题的思路更优，但是处理解决故障的过程每一步都不能少。

即便是做了N多年的老鸟，碰到上述的业务报障，也只能一个号码一个号码地去查用户资料、查业务办理记录、查工单执行记录、查报错日志……

再根据各种资料表、台帐表、日志信息中的蛛丝马迹判断用户投诉问题产生的原因。

每一个运维苦逼，都不会忘记他人生第一个问题的处理过程，这个过程即忐忑又兴奋，搞完之后还有写一部福尔摩斯探案之业务运维捉奸记的雄心壮志。

但当你日复一日，年复一年的做着换汤不换药的事情时，那种暴躁感，无时无刻不包裹着你，让你即压抑又面红耳赤……

无数个上线，排障的夜晚都有“世界这么大，我想去看看”的冲动。无奈空瘪的钱包，不断掐醒自己的同时，告诉自己，冷静，冷静，要冷静……

作为一个有思想的的运维人员，必须得想想办法，不能总是摁着一个小电影看不是，总干些重复劳动，我就问自己，手痛不？

望着自己手上的老茧，我下定决心，怀揣找人要小电影的心情，去找开发的小伙伴商量。咱能不能做些自动或者半自动的处理界面，把投诉报障工单里需要登录各平台查询的信息，根据需要自助查询展示出来。

以此咱就不用每次查一大堆东西，登录完CRM，登录ACT，登录完ACT，登录JF，再加上相关业务日志，平台日志。每查询间的切换耗时，都可以让哥看完一个小电影了。

如果展示的时候还能把关键信息标识加亮展示出来就更好了，再进一步，如果能把处理方案，做成依托平台的动态知识库直接给咱一个提示，或者干脆一键自动处理完报障，那就更爽了……哈哈哈，事隔多年，我仍清晰记得自己当时说得两眼放光，仿佛见到佛祖一样的兴奋场景。

我唾沫横飞地自淫了半小时，一脸期待地看着开发小伙伴。他很淡然的将脸从电脑屏幕前向我斜了5度，顺带瞟了一眼，说：“好啊，你和老大说一下，把我手头这些催命的开发需求往后挪挪？”

我：“……”

在我转动眼球的间隙，小伙伴又转回刚才的5度角继续敲代码，随带飘了一句说：“都是卖身的，规矩大家都懂哈，先找妈咪！”

想起如果能工具化之后，自己可以有大把时间撸自己喜欢做的事情，我又借着兴奋劲儿去找“妈咪”项目经理商量。

把刚才和开发小伙伴叨叨的话，又和妈咪叨叨了一遍，“咱能不能这样…这样…这样？”

妈咪很冷静，一看就是见过大场面的人，先肯定了我，说“你的想法很好”，接着话锋一转，“不过运维工作内容的变动多，需求不明确啊！你说的这些工单，每次上线可能导致的问题点都不一样，要查的东西不一样，处理过程更不一样。没有明确的处理逻辑，怎么弄个固定流程出来开发？总不能出一个问题开发一个功能吧。再说，开发有周期，等功能开发好上线了，这个问题热点都过了，功能不是白费了吗？”

现在想想当年妈咪的口活就是好，他这炮弹样儿的美颜灵魂N连问，让我瞬间软了，呃……

自此，一颗为运维人做些什么的种子在我的心中埋下了根。本着为运维人做些什么的想法，我后来从运维岗转到了产品岗。

理想是丰满的，现实是骨感的。在自己为运维人做些什么的种子长大的过程的，自己也折腾了不少bug出来，让曾经的运维同事掀了桌子，但那一刻更坚定了自己的初衷。

说个题外话，虽然开发和运维都很苦逼，但认真比对一下，我认为没有工具依托的运维是个更苦逼，更委屈的活儿。问题都不是自己产生的，不但要帮着擦屁股，还要挨骂的永远是运维人。这种心里的憋屈，没有体验过的人是不能感同身受的......

在做产品开发的日子里，每当自己稍闲下来的时候，为运维人做些什么的躁动仍然燃烧着我，那种感觉就像看了小电影，老婆没在身边的感觉一样。有没有什么产品方案能减轻一些运维人员的苦力，压力？

基于产品的角度，我重新梳理运维工作的现状和需求痛点，对于日常工作在一线的运维人员，需要构建一套具备运维自助能力平台，以此满足日益增长的运维需求。

1. 运维人员往往不具备开发环境，开发所需要的版本管理、开发资料在运维人员使用的安全环境中，便捷性是得不到保障的。

2. 运维人员的开发能力大部分聚焦在使用数据库的SQL语句及相关脚本语言。而开发一个完整的系统，从登录到权限管理、菜单页面、后台功能，再小的麻雀须要五脏俱全，否则难以推广使用。

3. 基于事务式的运维任务很多是临时性的，很多同类的任务处理频次往往随着一次系统的变更而爆发，一个并不长的周期之后，随着系统的逐渐完善又逐渐降低或再不需要处理，这是咬牙式纯项目开发带来的一个窘境。

4. 运维人员的工作种类繁多，日常的投诉工单处理、生产数据的生命周期管理、各种运维报表（kpi日报、周报、月报等）、系统监控巡检、突发故障处理等等，留给运维人员的余额时间不足。

5. 目前市面上的自动化运维工具或平台主要针对的是paas层的运维管理，对于基于业务层拉通后的OPS运维难以解决。

1、排障过程中，大量数据获取的支撑

运维排障过程中所需要访问的数据是海量的，需要连接各种不同业务系统中数据库的业务数据、系统性能指标数据、日志文件数据等来帮助问题的判断，想要查什么数据，都可快速在平台里获取到。

TIP：脱敏！脱敏！脱敏！安全之责不可少啊！

2、零开发

零开发！零开发！零开发！重要的事情说三遍。对于开发人员来说，实现一个具体的需求功能，开发代码也许并没有那么难，但对于运维人员来说，真的是臣妾做不到啊~

3、场景可配置

对于运维来说，场景化功能是刚需。场景可能是一个投诉工单的处理流程；可能是一个系统故障点的发现及自愈处理流程；可能是领导交代的一个取数任务；可能是每天要出具一份新业务的态势报告。无穷尽的场景不能通过一个个的开发定制来实现，要能通过通用的功能配置实现。配置的过程要足够快捷，且易用性要高，复用性高。否则问题周期都过了，场景还配不出来，运维是会掀桌子滴~

4、数据操作可关联

运维在排障查数据时，往往不是只查一个表的数据，而是查完第一张表，再根据第一张表中的某条记录再查第二张，第三张、第四张……所需要查看的数据随着业务流程的复杂度而增加，甚至还要查日志、查代码。所以功能上要实现数据查询的可关联性，通过参数化查询结果来实现其他数据的查询。

5、数据展现的灵活化

数据库中的数据往往是表格化展现的，其中数据的变化逻辑难以通过表格形式直观展现，大量的可视化界面成为高效手段方式。不同的数据需要不同的展现形式，需能通过灵活的配置提供不同的数据展现。如常规的柱状图、曲线图、饼图、雷达图、面积图都是运维数据展现所应该具备的。

6、界面布局配置的灵活化

一个场景功能的可用性，与界面布局是否合理息息相关。场景展现是上下结构，还是左右布局，得由运维人员自己说了算。不好用的界面操作逻辑，运维人员会说还不如直接查表来得直观快捷。

7、数据分析及处理过程可配置

正常开发中对于数据的使用不只是展现，还需要对数据做各种聚合或转换的运算操作。开发人员可以用代码来实现，但运维人员在不能写代码的情况下要实现数据处理，必须得提供一套可配置的通用数据处理模块来实现。这个数据处理要能做批量数据分析处理，还要能做实时数据分析处理……

8、要能对接自动化处理

毕竟咱是做自动化产品的公司，各个场地要随时可对接已有运维类的产品工具。

9、界面可视化要美观

是的，这是个看颜值的时代……

10、重点信息要能凸显标记

11、要有自配置大屏

此时我脑海里闪现出前端美女茜茜那能杀死我的眼神，弟弟一抖，不寒而栗，拉住了如脱缰的野马一般扩张的思路。

所以笔者拟定了第一版的场景化运维平台的功能架构：

(开发过程中的艰辛省略5万字……)

念念不忘，必有反响。笔者所在的团队终于将第一版的场景化运维开发平台上线了。

厉害我平哥，人狠话不多。废话不多说，先给大家看看一些场景效果图：

上面图片是通过业务链大屏配置功能配置出的某业务系统的可视化展现，以应用及应用关系为主要展现目标，展现各应用的实时运行状态。

各应用节点上可展现多维度指标，如负载主机数量、应用实例数量、异常实例数量、告警数量等信息；

应用节点连线代表应用之间的调用关系，以动画连线代表调用方向。连线上展现的指标可自由增加配置，如配置业务的调用总量、调用失败率、调用耗时等指标。

应用配置了下钻展现页，展现此应用的物理部署视图，包含主机、应用实例、交换机、网络等层级关系的展现，以及各实体的性能指标展现。

要特别说明的是，应用主机以及应用关系，都是根据数据自动生成，无需手动逐一配置，以此大大降低了运维人员在配置这种展现图时的工作量。

上面的图表展现，均是通过平台的kpi日报功能配置实现，通过配置数据口径及展现图表即可实现运维数据的可视化soeasy~，妈妈再也不用担心我的运维了......

图表之间配置了联动关系，点选某个节点或某个曲线中的时间点数据，可自动根据其代表的对象来获取下钻的明细数据，图例中通过指标告警快速定位并下钻到告警业务自检场景。

而各表格之间，可通过配置的下钻功能和联动功能，自由跳转查看相关数据。

该产品平台一切，都围绕可自由定义这个目标来实现。

上图是数据分析处理过程，通过底层的通用数据处理逻辑来实现数据的实时处理（基于flink平台的数据处理能力相当强大，谁用谁知道，哈哈哈~）

各类数据指标通过配置生成，后台同样通过搭建在flink实时计算平台的通用计算模块来实现数据处理。

目前此平台已在笔者所在的客户现场上线运行。这套系统涵盖了从自定义数据采集，到自定义数据处理逻辑，最后到自定义前台展现的各功能模块。运维人员可通过这套平台自己搭建所需要的运维场景。

目前已实现的场景包括：

缴费不开机投诉场景

优惠计费不准确投诉场景

业务办理失败投诉场景

业务互斥场景

宽带业务办理异常场景

各环节工单积压场景

工单应急开机处理场景

数据库巡检场景

中间件巡检场景

数据库故障处理场景

业务链大屏场景

数据库大屏场景

……

以上，是一个老运维人本着为运维人做点什么的初心，这些年来和小伙伴们一起迭代出来的阶段性成果，写出来，和大家分享一下，毕竟在这“疫满人间”的时刻，我们需要更多的温暖。

如果你需要了解产品的详细信息，请后台留言。

说好的小视频，在这里：