黑基网 首页 学院 系统管理 查看内容

「原创故事」运维的一天:架构设计、故障处理、人员离职……

2017-7-6 00:24| 投稿: xiaotiger |来自: 互联网

摘要: 高效运维社区致力于陪伴您的职业生涯,与您一起愉快的成长。作者简介:韩晓光DevOps Master、信息系统项目管理师、ITIL Foundation、RHCE。GOPS金牌讲师、金牌作者。著有《系统运维全面解析:技术、管理与实践》一书 ...

高效运维社区致力于陪伴您的职业生涯,与您一起愉快的成长。

作者简介:

韩晓光

DevOps Master、信息系统项目管理师、ITIL Foundation、RHCE。GOPS金牌讲师、金牌作者。著有《系统运维全面解析:技术、管理与实践》一书。

本文导读:

本文以叙事形式浓缩了很多运维场景、技术与总结。目录结构如下:

文中也提到一些问题困惑,作者希望以文互动,隔空问答,请读者探讨交流,同时点名了几位业内大咖祈求答疑解惑。

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

1、项目管理及云计算架构

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

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

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

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

1)重要而且紧迫;

2)紧迫但不重要;

3)重要但不紧迫;

4)既不重要又不紧迫。

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

这个项目重大,我们将通过这些重大项目促进公司全面升级转型技术架构,由传统信息化建设转型深化移动互联网式发展,向资源集约型,平台支撑型转变,提供持续集成与优化服务,趋向敏捷快速交付,由单一的运维资源交付转型全面云化生态运营交付。我们的云计算架构体系如下:

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

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

2、高效会议管理

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

  1. 借鉴《罗伯特议事规则》。例如会议要有主持人、记录人以维持好会议执行效力;会议要有具体、明确、可操作的行动建议。会议要有大小主题,不要跑题,发言有序、有时限。就事论事,不人身攻击,不质疑私人偏好,习惯,文化观等。

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

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

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

(1)云计算核心网络跑内部BGP及OSPF问题,

(2)通过VRF解决多VPN路由转发问题。

这些问题都很棘手且重要,因此问题交由王宜牵头解决。王宜是我们的一个全栈型SRE人才,从前端CDN、负载、代理到后端数据库、存储样样通,熟悉网络架构,我们的新建IDC网络架构就是他主导设计的,他还能写的一手好代码,我们的运维自动化平台的核心模块也是他主要完成的。

但有些遗憾的是王宜同学总是喜欢上来就干,不喜欢写规划,不喜欢写文档总结,无法协调好团队。自打让他负责带团队之后,结果依然是他一个人在全线战斗,没有发挥整个团队的价值。

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

@陈桂新,桂总您是如何辩证地看待运维技术与运维管理关系的?

3、网络安全管理

项目会刚开不久,这时网络安全负责人刘森,神色凝重,让我出来一下,我跟着他到了隔壁会议室,刘森拿出一分文件让说,这是内部安全审计结果,我们还有安全漏洞,需要立刻整改,否则下周一外部审计过来就不合适了。我看了看看报告,其中提到安全问题概要如下:

现在网络安全是运维常态化重点工作,我们通常定期做安全漏洞扫描、渗透测试。针对安全漏洞,我们常用的漏洞修复策略如下

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

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

  3. 严格堡垒机访问权限,什么角色的人使用什么权限;

  4. 加强系统iptables访问策略,严格应用访问策略;

  5. 修改相关系统的账号密码;

  6. 升级打补丁,修复系统、应用漏洞;

  7. 清理有木马等异常的系统服务器。;

由于是限期安全整改,截止到下周一必须完成。我们得立刻找人手开始修复漏洞。考虑到这次安全限期整改的重要紧急性,我安排王宜加入刘森安全整改项目组。

王宜是一个全栈型技术人才,希望他能帮助刘森尽快解决这些安全问题。

4、运维自动化架构设计

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

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

通过运维自动化管理解决方案融合、统一管理运维人员、资源、事件流程,统一监控管理IT资源,有效关联整合数据信息,从而促进运维管理工作的标准化、流程化、可视化、自动化、智能化、产品化。最终目标是要提供更好地运维服务交付能力,更好地支撑我们当前及未来业务快速稳健发展。

如下是本运维自动化系统逻辑架构规划图。详细内容介绍请参考作者文章《运维自动化与标准规范化:解析、设计及实现 | 操作指南式的实战》。

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

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

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

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

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

@王津银,王总您是如何设计运维自动化解决方案的?

5、项目团队管理

上午的项目会、安全事情和一些运维琐事交织在一切,让人感觉时间飞快。

眼看就要12:00了,我看见刘森和王宜好像还在因为安全修复项目组怎么组建、怎么分工,怎么开工的事情争论不断。我忍不住过去也加入了他们的争论之中。

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

说完我先走了,我得赶紧吃点午饭,准备一些材料。下周需要召开立项研讨会。我打算升级优化核心数据库系统的技术架构,为此我已初拟了个立项报告。

考虑到项目重大,我需要今天下午提前向老大汇报征求一下意见。

6、两地三中心架构概述

下午14:00,我准时来到老大的办公室,我直奔主题说明我的想法。由于历史原因,我们的这组核心数据库系统存在一些隐患:

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

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

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

因此我建议重新升级优化架构,从整体设计上解决这些问题,主要思路如下:基于两地三中心大量成熟方案,构建同城双活实时同步,异地灾备异步同步体系,实施双机RAC+Dataguard双层冗余,基于应用、数据库及存储阵列级多层次数据同步,通过存储连续性保护应对应用逻辑故障,外加磁带归档存储。两地三中心是什么样的架构,下面我给一个示意图例

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

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

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

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

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

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

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

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

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

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

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

我有种顿悟的感觉,但同时我也想赶紧离开这里。

突然我的手机短信响了,是一条告警显示“严重故障,mysql主从不同步”,我有种得救的感觉。赶紧说“有个监控告警,小故障,我得去了解下情况”,说完赶紧从办公室出来了。

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

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

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

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

我没有再说什么,只是在想,其实我更希望王宜他们团队的组员去处理(而不是王宜直接处理),希望发挥其团队每个人的价值。但我又想,王宜本身也需要锻炼团队管理协调能力,所以还是由王宜自己判断如何协调团队工作吧。

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

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

我先说说的拙见吧,传统运维与互联网运维的差异,可以归结为6大差异,如下:架构差异、工作内容差异、知识体系差异、面向对象差异、运维人员差异、体制理念差异。

这里只摆放一个架构差异的图解,如下图所示。(具体阐述请参见作者文章《传统运维 VS 互联网运维 从哪来到哪去》)。

说到运维知识体系,@赵舜东(赵班长)总结的非常到位,那么我有一个问题请教赵总:您构建起的运维知识体系是如何输出价值,以支撑服务好业务(客户)?

8、网络大流量事件处置

这时张驰快步向我走来,看着有些着急:有故障,我们的多个域名打开异常缓慢,网站性能监测频发告警。虽然我干IT工作10余年了,但当我听到“故障”这俩字,仍然感觉刺耳敏感。

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

基于网站架构及网民访问的数据流向,我们逐个排查CDN、源站、负载均衡……很快,我们发现一个老旧负载均衡设备上并发连接数激增,如下图所示。

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

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

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

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

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

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

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

@许颖维:请问许总,你是如何运维好你们大数据业务系统的?

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

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

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

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

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

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

  3. 通过session会话、cookies验证来防止恶意刷票。

  4. 通过实名制登记、登陆验证码等来防止恶意刷票

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

9、人员离职现象与原因概括

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

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

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

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

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

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

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

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

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

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

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

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

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

“啊?”我没继续说。

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

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

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

@梁定安:把这么一个敏感话题交给大梁总,请问您是如何看待与处置人员离职问题的?

10、变更经验总结

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

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

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

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

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

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

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

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

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

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

11、运维架构体系规划

这时我突然想起老大的提醒,我应该从架构体系的层面梳理解决当前一锅粥似的一系列问题。运维架构体系是运维的基础及核心竞争力。通过运维体系的构建及完善,使我们的运维做到稳定可靠,准确完备,规范科学。

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

前文已阐述了传统运维与互联网运维的不同层面维度的差异,但从另一方面来看,作为运维,还是有很多共同之处。这里我将从一个架构高度看待和规划运维,如下图所示。

小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册黑基账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!

本文出自:http://www.toutiao.com/a6439060069371560194/

免责声明:本文由投稿者转载自互联网,版权归原作者所有,文中所述不代表本站观点,若有侵权或转载等不当之处请联系我们处理,让我们一起为维护良好的互联网秩序而努力!联系方式见网站首页右下角。


鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论


新出炉

返回顶部