IT运维笔记:操着卖白粉的心,赚着卖白菜的钱!

2017 年 11 月 30 日 51CTO博客 韩晓光

本文故事场景纯属虚构,人物皆为化名,除此之外都是实在干货。


本文以叙事形式浓缩了很多运维场景、技术与总结。作者探讨了:项目管理、云计算架构、高效会议管理、网络安全管理、运维自动化架构设计、项目团队管理两地三中心架构、人员管理、运维架构体系规划、运维感悟等等与运维密切相关的典型案例及场景。


项目管理及云计算架构


今天周五,多云雾霾,我到了单位,接杯水瞅了瞅窗外,云遮雾罩,有种做梦的感觉,不知为啥眼睛跳的厉害,这不是好兆头。


我习惯先打开邮箱,再打开即时通讯软件,再打开云笔记,看看 24 小时值班情况、工作邮件、项目邮件、即时消息和技术文章,通过这些内容信息基本上能概览昨天工作和今天要干的事情,同时了解一些最新技术动态。


面对朦胧的窗外,我在想:工作人生就是在层层迷雾中探索,不断拨云见日,开拓眼界和道路,实现虚拟梦境到现实世界的转变。

看完邮件和一些 OA 内容,我把今天要做事情划分四个层次:

  • 重要而且紧迫。

  • 紧迫但不重要。

  • 重要但不紧迫。

  • 既不重要又不紧迫。


上午 10:00,我要召开每周项目例会,讨论云计算项目进展情况和后期安排,做好四控两管一协调工作(我好像干了监理的工作)。


这个项目重大,我们将通过这些重大项目促进公司全面升级转型技术架构,由传统信息化建设转型深化移动互联网式发展,向资源集约型、平台支撑型转变。


并提供持续集成与优化服务,趋向敏捷快速交付,由单一的运维资源交付转型全面云化生态运营交付。


我们的云计算架构体系如下:

围绕上述架构原型,我们要在特定时间、预算、资源限定内依据规范完成云计算项目建设,时间紧任务重,整个项目组压力大,动力也大。


说到项目管理,它是一门大学问,做运维管理、系统集成,信息化建设,项目经理等工作都需要了解,这里梳理了一个项目管理 5 大流程 10 大知识领域知识图,有兴趣大家可以看看 PMBOk 等相关资料,这里不再赘述。

高效会议管理


说到开会,也是一个技术活。为了提高会议效率和效能,我通常会这么做:

  • 借鉴《罗伯特议事规则》。例如会议要有主持人、记录人以维持好会议执行效力;会议要有具体、明确、可操作的行动建议。

    会议要有大小主题,不要跑题,发言有序、有时限。就事论事,不人身攻击,不质疑私人偏好,习惯,文化观等。

  • 提前发会议议题,资料。避免会上临时看资料,临时讨论,所有都是临时拍脑袋,导致会议冗长、效能差。

  • 做好会议纪要,遵循 SMART 原则。明确会议的结论,任务、执行人和期限,做好工作任务追踪、追溯。


关于我们云计算项目进展,我看了下上周会议纪要,当前还有两个重要问题待解决:

  • 云计算核心网络跑内部 BGP 及 OSPF 问题。

  • 通过 VRF 解决多 VPN 路由转发问题。


这些问题都很棘手且重要,因此问题交由王宜牵头解决。王宜是我们的一个全栈型 SRE 人才。


他从前端 CDN、负载、代理到后端数据库、存储样样通,熟悉网络架构,我们的新建 IDC 网络架构就是他主导设计的,他还能写的一手好代码,我们的运维自动化平台的核心模块也是他主要完成的。


但有些遗憾的是王宜同学总是喜欢上来就干,不喜欢写规划,不喜欢写文档总结,无法协调好团队。


自打让他负责带团队之后,结果依然是他一个人在全线战斗,没有发挥整个团队的价值。


为此我跟王宜谈了多次,期望他能发挥更大能力,每当我们讨论到技术和管理的平衡关系时,最终往往陷入到底技术重要还是管理重要的漩涡中。不知广大读者朋友有何见解?

 

网络安全管理


项目会刚开不久,这时网络安全负责人刘森,神色凝重,让我出来一下。


我跟着他到了隔壁会议室,刘森拿出一份文件来说,这是内部安全审计结果,我们还有安全漏洞,需要立刻整改,否则下周一外部审计过来就不合适了。


我看了看报告,里面提到的安全问题概要如下:

现在网络安全是运维常态化重点工作,我们通常定期做安全漏洞扫描、渗透测试。


针对安全漏洞,我们常用的漏洞修复策略如下:

  • 严格各区域之间访问限制与隔离,阻止服务器之间的互相访问,防止内网移动渗透。

  • 下线有问题的系统,保留证据,重新安装部署备机后再上线。

  • 严格堡垒机访问权限,什么角色的人使用什么权限。

  • 加强系统 ip tables 访问策略,严格应用访问策略。

  • 修改相关系统的账号密码。

  • 升级打补丁,修复系统、应用漏洞。

  • 清理有木马等异常的系统服务器。


虽然有上述很多安全防护措施,但我们总还隐约担心安全,有种一入安全深似海,回首沧桑惊心怀。也因此我们正在探索从整体网络架构、安全架构层面彻底解决安全防控问题。


由于是限期安全整改,截止到下周一必须完成。我们得立刻找人手开始修复漏洞。


考虑到这次安全限期整改的重要紧急性,我安排王宜加入刘森安全整改项目组。王宜是一个全栈型技术人才,希望他能帮助刘森尽快解决这些安全问题。


运维自动化架构设计


对于批量增删改查、密码查询修改,批量打补丁,系统部署,监控管理等工作,我们有自己研发的一套运维自动化综合管理平台,总体功能框架设计如下图:

本运维自动化是一体化解决方案,从我们的实际业务需求出发,基于 DevOps 理念,引入轻量级 IT 服务管理体系,以 CMDB 资源管理为核心驱动,围绕运维监控及自动化管理为建设主体,构建起敏捷运维服务管理体系。


通过运维自动化管理解决方案融合、统一管理运维人员、资源、事件流程,统一监控管理 IT 资源,有效关联整合数据信息,从而促进运维管理工作的标准化、流程化、可视化、自动化、智能化、产品化。


最终目标是要提供更好地运维服务交付能力,更好地支撑我们当前及未来业务快速稳健发展。


如下是本运维自动化系统逻辑架构规划图:

对于运维自动化系统的设计与实现思路,我们老大(后文即将出场)曾提出了他的一些建议:

  • 功能要精专,模块要解耦,不要过度设计。

  • 产品要实用,能够很好支撑业务,而不是仅仅做成纯技术理论产品。

  • 运维自动化是把双刃剑,要特别注意安全防护和权限控制。


对此我有些不解,我总想把该系统做成大一统紧耦合,自动化到极致,寄希望于运维自动化解放运维人员,但实际情况我逐渐领悟到二八原则和中庸之道,凡事要适度恰到好处,凡事要柔韧不可用尽。


项目团队管理


上午的项目会、安全事情和一些运维琐事交织在一切,让人感觉时间飞快,眼看就要 12:00 了,我看见刘森和王宜好像还在因为安全修复项目组怎么组建、怎么分工,怎么开工的事情争论不断。


我忍不住过去也加入了他们的争论之中,我把我总结的布鲁斯·塔克曼的团队发展阶段模型及应对措施给他们讲了讲,希望他们能从中获得一些价值和帮助。

说完我先走了,我得赶紧吃点午饭,准备一些材料。下周需要召开立项研讨会。


我打算升级优化核心数据库系统的技术架构,为此我已初拟了个立项报告。考虑到项目重大,我需要今天下午提前向老大汇报征求一下意见。


两地三中心架构概述


下午 14:00,我准时来到老大的办公室,直奔主题说明我的想法。


由于历史原因,我们的这组核心数据库系统存在一些隐患:

  • 有些模块的数据库 rac 集群心跳线还是百兆,无法保障集群的性能及稳定性。

  • 存储阵列已经过保,而且容量及性能都有限,难以支撑系统业务发展。

  • 当前缺乏有效地数据备份及灾备保护。


因此我建议重新升级优化架构,从整体设计上解决这些问题,主要思路如下:

  • 基于两地三中心大量成熟方案,构建同城双活实时同步,异地灾备异步同步体系,实施双机 RAC+Dataguard 双层冗余。

  • 基于应用、数据库及存储阵列级多层次数据同步,通过存储连续性保护应对应用逻辑故障,外加磁带归档存储。


两地三中心是什么样的架构,下面我给一个示意图例:

我认为我考虑地很周全,我稀里哗啦说了一通,但发现老大没有欣赏之意。


老大问:“你是否与业务部门,研发部门,商务部门一块讨论过这个方案?”


“这个……没有…….”我支支吾吾说:“我觉得这是纯技术方案…..”


老大又问:“互联网运维和传统信息化运维有区别么?”


“这个,那个…..”我一时间脑袋空白了。


老大继续再问:“你这方案的优化创新思路在哪里?”


这时我感觉一股冷气直入后脊梁,头脑飞速但凌乱:“我这个方案有很多成熟案例,这种技术架构已有好多年了……”


“是好多年了,你还在照搬多年前的技术架构,方案毫无创新。”,老大若有所思:

  • 首先你应该了解业务,技术与业务不能两张皮,技术要与其他部门业务协同,技术要支撑业务发展。

  • 其次咱们不能再走传统信息化那种封闭竖井式道路,要走平台化、集群分布式、敏捷可持续、开放互联、合作共赢的生态道路。

  • 最后再次提醒你们,从业务到技术到运营,你们需要互相协同与支持。


我有种顿悟的感觉,但同时我也想赶紧离开这里。突然我的手机短信响了,是一条告警显示“严重故障,MySQL 主从不同步”,我有种得救的感觉。


赶紧跟老大说:“我有个监控告警,小故障,得去了解下情况”,说完赶紧从办公室出来了。


我走到王宜那里问:“谁在处理 MySQL 主从不同步的故障?”


王宜很自信地说:“我在处理,这个小问题我能解决。”


“安全漏洞防护进展咋样了?”我问。


“刘森让我帮助他做系统安全加固和打补丁”,王宜有些无奈地表情说:“他根本不了解我这边工作情况,我今天一直在忙,根本没时间做系统安全加固的事情,等我把 MySQL 的问题解决了,再做系统 ip tables 控制策略…..”


我没有再说什么,只是在想,其实我更希望王宜他们团队的组员去处理(而不是王宜直接处理),希望发挥其团队每个人的价值。


但我又想,王宜本身也需要锻炼团队管理协调能力,所以还是由王宜自己判断如何协调团队工作吧。

 

传统运维 VS 互联网运维异同对比


我走回自己的办公位,冥思苦想互联网运维与传统运维有什么区别呢?不知广大读者朋友有何见解?我先说说拙见吧。


传统运维与互联网运维的差异,可以归结为如下 6 大差异:

  • 架构差异。

  • 工作内容差异。

  • 知识体系差异。

  • 面向对象差异。

  • 运维人员差异。

  • 体制理念差异。


这里只摆放一个架构差异的图解,如下图所示:

网络大流量事件处置


这时,张驰快步向我走来,看着有些着急:有故障,我们的多个域名打开异常缓慢,网站性能监测频发告警。


虽然我干 IT 工作 10 余年了,但当我听到“故障”这俩字,仍然感觉刺耳敏感。


作为运维人,经常要救火,头脑需要冷静,做到胆大心细,行事可以忙但不能乱。对于这种访问故障,我们通常会基于网络架构层次逐个捋顺排查和定位。


网站架构通常如下图所示:

基于网站架构及网民访问的数据流向,我们逐个排查 CDN、源站、负载均衡……


很快,我们发现一个老旧负载均衡设备上并发连接数激增,如下图所示:

根据我们以往经验,这种突发激增往往由某种网站活动引起的。


经过网安部梳理 CDN 监测信息、负载情况、域名网站、流控监测信息,网站业务运行信息,我们很快确定了部分网站缓慢原因。


由于恶意刷票导致突发大并发连接,过度消耗设备性能,由于这台负载老设备处理并发性能有限,因此该负载下网站都出现了访问缓慢问题。


我看了下时间 17:45,网安部门刘森向我走来,他怀着一种庆幸(找到了问题原因)和一些委屈(又是投票,这是业务层面事情,不是运维导致的故障)向我反馈详细故障由来。


等他说完原因,我问道:“业务影响范围有多大?后续如何处置?什么时间彻底解决?”


对于这些问题,刘森貌似还没准备好如何回答。


我接着说道:做运维需要熟悉业务才能更好地支撑业务,基于业务场景的运维是运维价值观的重要体现。


这个时候,我们老大也走了过来:“问题解决怎么样了?要抓紧解决,不要保留问题过夜”,老大又说:“发生了这么多问题,你们要从架构体系层面高屋建瓴式地解决问题,而不是天天忙于被动救火”。


我回答道:“好的,我赶紧落实处理恶意刷票问题……”。


老大又说道:“还有,你们要考虑如何升级转型架构体系,遵循公司战略目标,通过技术创新升级并引领业务发展”。


对于老大的建议,我若有所思…..不过我还是先解决当下棘手的刷票问题吧。对于这种恶意刷票现象,很多行业已屡见不鲜了,考虑到投票业务多样性,我们运维解决思路也有很多方式。


列举如下:

  • 调整负载均衡流量,将大流量的业务切换到小流量的负载上,或者单独配置(软、硬)负载。

  • 使用 IP 地址过滤,通过 CDN、前端防火墙、负载、代理、Lua 等软硬件对恶意 IP 进行过滤。

  • 通过 Session 会话、Cookies 验证来防止恶意刷票。

  • 通过实名制登记、登录验证码等来防止恶意刷票。

  • 把业务搬到公有云上,借助公有云资源来防护恶意刷票,也是一种手段。

 

人员离职现象与原因概括


不知不觉时间已经 18:50 了,这时我们值班服务台 Service Desk 同事打回电话说(需要二线支持),业务部门反映发布系统非常缓慢,甚至打不开,图片、JS、CSS 加载缓慢。


但我查看网站性能监控并未告警,从监控来看有些波动,但貌似没有太明显异常。

这是为什么?这可能是前端或系统相关问题,我想找王宜核查一下,但刘森说他已经下班走了。


“他不是在帮助你解决安全防护的问题么,怎么没有个里程碑式结论就走人了?”我有些诧异。


“这个安全事情。。。。。咱们待会再商议吧”,刘森无奈地说“我现在给王宜打电话,优先处理业务用户反馈问题”。


稍后刘森说:“王宜电话没人接,您看下步怎么办?”


这时我脑子里首先一闪念,想起了一个运维前辈曾经给我说过“做运维工作,要有高度责任心,不甩锅不背锅”。


我拿起电话,直接拨通了王宜团队的组员李智的号码。我把问题现象给他描述了一下。


李智说:“头,这个问题现象有些笼统,咱们今天都做过什么变更么?”


我犹豫了一下,“今天的变更有很多,不过你先查查前端系统吧,我再找人查其他环节”。


李智也犹豫了一下“……我可能最近也要变动一下…..”


“你说什么?”我好想没听懂。


“我正想找您说这事……”李智说“我打算离职了……”


“啊?”我没继续说。


“这个回头再说吧……”李智转移了话题“我先处理问题吧”。


我挂下电话,有种焦头烂额的感觉。我想了想:铁打的营盘,流水的兵,离职倒也是正常现象。


可能离职原因多种多样,但归纳起来,(借鉴马斯洛需求层次理论)无外乎以下几种诉求得不到满足:生理需求(工资待遇)、安全需求(公司内外环境)、社会需求(文化、社交)、尊重的需求(人文关怀、团队建设)、自我实现的需求(职业发展)、自我超越的需求(人生发展)。

变更经验总结


我还在猜想李智的离职原因,这时王宜电话打回电话说刚才没听见电话响。我把问题给他又复述了一遍,他好像知道了什么。


“可能由于批量化操作,导致前端有组特殊的 Ngnix 系统的 ip tables 配置错了”,王宜说:“估计李智不清楚这套系统环境,所以这事还是由我来处理吧”。


没过一会,王宜反馈说问题解决了。主要原因是:这组特殊的 Ngnix 在负载后面,但由于错误的 ip tables 策略,收到负载请求则不处理丢弃,因此造成超时 TCP 重传,负载只能再向 Ngnix 分配请求,如此造成访问请求缓慢不稳定。


虽然问题解决,但我总结教训如下:

  • 尽量避免变更,应保持不可变基础设施。

  • 一次变更只做一件事,同时做好变更的记录。

  • 条件允许的话,在做变更之前先做好测试、应急回退措施。

  • 做变更最好有实施者,有复核(配合)人员,有工作互备人员。最好能做到相关人员周知。

  • 变更最好周五之前做,夜晚做。

  • 运维自动化的确是把双刃剑,没有标准化、流程化的批量自动化可能是灾难。

 

运维架构体系规划


这时我突然想起老大的提醒,我应该从架构体系的层面梳理解决当前一锅粥似的一系列问题。运维架构体系是运维的基础及核心竞争力。


通过运维体系的构建及完善,使我们的运维做到稳定可靠,准确完备,规范科学。


以面向服务、持续交付为核心,从人、事、物、流程这四个方面把运维体系进行解构,它们彼此互相作用,共同构建了一个完整实用的运维体系。

前文已阐述了传统运维与互联网运维的不同层面维度的差异,但从另一方面来看,作为运维,还是有很多共同之处。


这里我将从一个架构高度看待和规划运维,如下图所示:

下面列举了这四个方面各自的含义及相关内容:

  • 人:例如完善岗位职责与职业发展、提高团队技术水平、完善技能分享与培训、完善团队绩效考核、规范工作行为规范等。

    目的是要建成一支工作高效、技术水平高、团结稳定、有职业素养的运维团队。

  • 事:例如做好日常基础运维工作,保障好生产业务运行。不断探索新的运维理念与技术,探索优化系统架构。

    具体可以分为几大块,例如运维流程管理,资源架构规划,应急与故障处理,监控与优化,安全与防护,项目及日常工作等等。

    目的是要明白运维做什么正确的事,怎么正确地做事,做事有章法,稳定高效能。

  • 物:主要是如何管理好系统运维所涉及的各种资源。例如机房环境、办公设备、服务器、网络设备、操作系统、应用软件、工具等各种软硬件资源。

    目的要使各类资源配置管理妥当,清楚资源属性,知道从哪来,现在哪,要去哪使得物尽其用,物有所值,安置妥当。

  • 流程标准:运用流程标准将上述要素(人、事、物)有机地结合,有序科学地流转、高效稳定地运行。

    例如资源规划与采购,各种标准规范、项目规范、软硬件配置部署规范、安全制度、工作交接等等。


如下列举一个安全岗位运维规划图:

想着想着,不觉得已进入深夜,我看下时间,晚上 22:17 了。忙碌了一天,感觉整个身体被掏空,终于回到家可以洗把脸睡了。


晚上做起了梦,梦境不可描述,我把这个奇葩的梦境画面贴出来,请读者帮我解梦,说说你们的理解。

运维同理心


这虽然是一个梦,但梦却是真实的表达。作为运维工作者,其中的酸甜苦辣,谁解其中味?也许谁干谁知道。


工作繁琐:采购设备软硬件,上架贴标签,系统环境软硬件部署,统计核实设备信息、复核系统变更情况,搬迁设备,调优系统……如此工作,日复一日,年复一年,会让人感觉无始无终。


鸭梨山大:有句话说的好“操着卖白粉的心,赚着卖白菜的钱。”,运维各种繁琐工作交织一块,在有限时间、精力和繁重工作情况下,我们倍感鸭梨山大。系统故障、上线、调优、升级、恢复等特殊环境下,我们的身心都面临着不可描述的感受……


设备系统故障:设备系统,尤其是过保的硬件设备,很容易出故障。机房环境、温湿度,业务的读写频繁度,业务人员野蛮地使用,各种因素都会导致设备系统意外故障。意外就是意外,往往出现在不恰当的时间、地点。经常会让运维人员莫名郁闷。


熬夜加班:有没有别人节假日团圆 Happy,你在苦逼的加班熬夜。有没有别人吃喝畅聊,你在角落里苦逼的远程 VPN,有没有三更半夜向特务一样起床敲代码,低声细语的频繁打电话?有没有。。。。。。?反正我都有。。。。。


IT 消防员:我们就是 IT 消防员,我们的最高境界就是无我境界,大家都很舒服时都想不起来我。一旦想起来我,可能IT环境出问题了。。。。。。我们只有硬着头皮去结尾,牺牲我一个,幸福一大家。


背黑锅:运维人员有天生背黑锅的宿命。当你找不出别人的问题时,那就只能背黑锅,或许找出问题,也可能一起背黑锅。任何行业工作都有其委屈尴尬的一面,背黑锅是运维人员成熟历练的必经之路。


我感觉梦里有种刺耳有熟悉的铃声响起,不……我突然醒了,原来是手机响了……..


作者:韩晓光

编辑:陶家龙、孙淑娟

来源:转载自高效运维微信公众号


韩晓光,Devops Master、信息系统项目管理师、ITIL Foundation、RHCE,著有《系统运维全面解析:技术、管理与实践》一书。

精彩文章推荐:

京东大规模数据中心网络运维监控之眼

阿里Dubbo疯狂更新,关Spring Cloud什么事?

饿了么业务爆发性增长欠下的“技术债”,迟早都是要还的!

登录查看更多
0

相关内容

运维,这里指互联网运维,通常属于技术部门,与研发、测试、系统管理同为互联网产品技术支撑的4大部门,这个划分在国内和国外以及大小公司间都会多少有一些不同。
德勤:2020技术趋势报告,120页pdf
专知会员服务
190+阅读 · 2020年3月31日
《代码整洁之道》:5大基本要点
专知会员服务
49+阅读 · 2020年3月3日
阿里巴巴达摩院发布「2020十大科技趋势」
专知会员服务
106+阅读 · 2020年1月2日
【电子书】C++ Primer Plus 第6版,附PDF
专知会员服务
87+阅读 · 2019年11月25日
阿里巴巴全球化架构设计挑战
InfoQ
35+阅读 · 2019年11月25日
【数字化】制造业数字化转型的实战路线图
产业智能官
39+阅读 · 2019年9月10日
5G时代:北京移动业务支撑系统 DevOps 实践
DevOps时代
15+阅读 · 2019年6月13日
工行基于MySQL构建分布式架构的转型之路
炼数成金订阅号
15+阅读 · 2019年5月16日
【工业大数据】工业大数据分析处理技术与应用
产业智能官
28+阅读 · 2019年2月2日
为什么分布式一定要有消息队列?
互联网架构师
4+阅读 · 2018年7月5日
一个人的企业安全建设之路
FreeBuf
5+阅读 · 2017年7月7日
Do RNN and LSTM have Long Memory?
Arxiv
19+阅读 · 2020年6月10日
Deep Co-Training for Semi-Supervised Image Segmentation
Self-Attention Graph Pooling
Arxiv
5+阅读 · 2019年4月17日
Doubly Attentive Transformer Machine Translation
Arxiv
4+阅读 · 2018年7月30日
Arxiv
4+阅读 · 2018年6月5日
Arxiv
10+阅读 · 2018年2月17日
VIP会员
相关资讯
阿里巴巴全球化架构设计挑战
InfoQ
35+阅读 · 2019年11月25日
【数字化】制造业数字化转型的实战路线图
产业智能官
39+阅读 · 2019年9月10日
5G时代:北京移动业务支撑系统 DevOps 实践
DevOps时代
15+阅读 · 2019年6月13日
工行基于MySQL构建分布式架构的转型之路
炼数成金订阅号
15+阅读 · 2019年5月16日
【工业大数据】工业大数据分析处理技术与应用
产业智能官
28+阅读 · 2019年2月2日
为什么分布式一定要有消息队列?
互联网架构师
4+阅读 · 2018年7月5日
一个人的企业安全建设之路
FreeBuf
5+阅读 · 2017年7月7日
相关论文
Do RNN and LSTM have Long Memory?
Arxiv
19+阅读 · 2020年6月10日
Deep Co-Training for Semi-Supervised Image Segmentation
Self-Attention Graph Pooling
Arxiv
5+阅读 · 2019年4月17日
Doubly Attentive Transformer Machine Translation
Arxiv
4+阅读 · 2018年7月30日
Arxiv
4+阅读 · 2018年6月5日
Arxiv
10+阅读 · 2018年2月17日
Top
微信扫码咨询专知VIP会员