linux运维工程师是做什么的从忙碌的一天说起

发布时间:3 年前栏目：行业详情浏览：次

从现在毕业了好多linux云计算的学生，可是还有特别多学员对于住驹己谩靠天的工作流程不太熟悉。今天小编特发文有关运维工程师的文章，但愿给你们一些协助。本文以叙事形式浓缩了特别多运维场景、技术与总结。从IT培训网现在毕业了好多linux云计算的学生，可是还有特别多学员对于住驹己谩靠天的工作流程不太熟悉。今天小编特发文有关运维工程师的文章，但愿给你们一些协助。

本文以叙事形式浓缩了特别多运维场景、技术与总结。
1、项目管理及云计算架构   每周项目例会,讨论云计算项目进展情况和后期安排，做好四控两管一协调工作。这个项目重大，我们将通过这些重大项目促进公司全面升级转型技术架构，由传统信息化建设转型深化移动互联网式发展，向资源集约型，平台支撑型转变，提供持续集成与优化服务，趋向敏捷快速交付，由单一的运维资源交付转型全面云化生态运营交付。我们的云计算架构体系如下：

围绕上述架构原型，我们要在特定时间、预算、资源限定内依据规范完成云计算项目建设，时间紧任务重，整个项目组压力大，动力也大。说到项目管理，它是一门大学问，做运维管理、系统集成，信息化建设，项目经理等工作都需要了解，这里梳理了一个项目管理5大流程10大知识领域知识图，有兴趣大家可以看看PMBOk等相关资料，这里不再赘述。

2、高效会议管理   说到开会，其实也是一个技术活。为了提高会议效率和效能，我通常会这么做：
1、借鉴《罗伯特议事规则》。例如会议要有主持人、记录人以维持好会议执行效力；会议要有具体、明确、可操作的行动建议。会议要有大小主题，不要跑题，发言有序、有时限。就事论事，不人身攻击，不质疑私人偏好，习惯，文化观等。
2、提前发会议议题，资料。避免会上临时看资料，临时讨论，所有都是临时拍脑袋，导致会议冗长、效能差。
3、做好会议纪要，遵循SMART原则。明确会议的结论，任务、执行人和期限，做好工作任务追踪、追溯。
4、关于我们云计算项目进展，我看了下上周会议纪要，当前还有两个重要问题待解决：
（1）云计算核心网络跑内部BGP及OSPF问题，
（2）通过VRF解决多VPN路由转发问题。这些问题都很棘手且重要，因此问题交由王宜牵头解决。王宜是我们的一个全栈型SRE人才，从前端CDN、负载、代理到后端数据库、存储样样通，熟悉网络架构，我们的新建IDC网络架构就是他主导设计的，他还能写的一手好代码，我们的运维自动化平台的核心模块也是他主要完成的。但有些遗憾的是王宜同学总是喜欢上来就干，不喜欢写规划，不喜欢写文档总结，无法协调好团队。自打让他负责带团队之后，结果依然是他一个人在全线战斗，没有发挥整个团队的价值。为此我跟王宜谈了多次，期望他能发挥更大能力，每当我们讨论过技术和管理的平衡关系时，最终往往陷入到底技术重要还是管理重要的漩涡中。不知广大读者朋友有何见解？
3、网络安全管理   项目会刚开不久，这时网络安全负责人刘森，神色凝重，让我出来一下，我跟着他到了隔壁会议室，刘森拿出一分文件让说，这是内部安全审计结果，我们还有安全漏洞，需要立刻整改，否则下周一外部审计过来就不合适了。我看了看看报告，其中提到安全问题概要如下：

现在网络安全是运维常态化重点工作，我们通常定期做安全漏洞扫描、渗透测试。针对安全漏洞，我们常用的漏洞修复策略如下：严格各区域之间访问限制与隔离，阻止服务器之间的互相访问，防止内网移动渗透；
1、下线有问题的系统，保留证据，重新安装部署备机后再上线；
2、严格堡垒机访问权限，什么角色的人使用什么权限；
3、加强系统iptables访问策略，严格应用访问策略；
4、修改相关系统的账号密码；
5、升级打补丁，修复系统、应用漏洞；
6、清理有木马等异常的系统服务器。
7、由于是限期安全整改，截止到下周一必须完成。我们得立刻找人手开始修复漏洞。
4、运维自动化架构设计   对于批量增删改查、密码查询修改，批量打补丁，软件部署，监控管理等工作，我们有别人研发的一套运维自动化综合管理渠道，总体功能框架设计如下图。

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

利用途径运维自动化管见解决方案融合、统一管理运维人员、资源、事件流程，统一监控管理IT资源，有效关联整合数据信息，从而促进运维管理工作的标准化、流程化、可视化、自动化、智慧化、业务化。尤其终目标是要支持更好地运维服务交付才气，更好地支撑我们当前及未来产品迅速稳健开展。如下是本运维自动化软件逻辑架构规划图。详细实质推选请参照作者文章《运维自动化与标准规范化：解析、设计及实现 | 操作指南式的实战》。
对于运维自动化软件的设计与实现思路，我们老大（后文即将出场）曾提出了他的一些建议：
1、功能要精专，模块要解耦，不要过度设计。
2、业务要实用，能够很不错支撑产品，而不是仅仅做成纯技术理论业务。
3、运维自动化是把双刃剑，要特别注意安全防护和权限控制。
4、对此我有些不解，我总想把该软件做成大一统紧耦合，自动化到极致，寄但愿于运维自动化解放运维人员，不过实际状态我逐渐领悟到二八原则和中庸之道，凡是要适度恰到好处，凡是要柔韧不可用尽。
5、式样团队管理   上午的式样会、安全事情和一些运维琐事交织在一切，让人感觉时候飞快。眼看就要12:00了，我看见刘森和王宜好像还在因为安全修复式样组怎么组建、怎么分工，怎么开工的事情争论不断。我忍不住过去也加入了他们的争论之中。我把我总结的布鲁斯·塔克曼的团队开展阶段模型及应对措施给他们讲了讲，但愿他们能从中获得一些价值和协助。
7、传统运维 VS 互联网运维异同对照我走回别人的办公位，冥思苦想互联网运维与传统运维有什么不一致的地方呢？不知广大读者挚友有何见解？我先说说的拙见吧，传统运维与互联网运维的差别，不妨归结为6大差别，如下：架构差别、工作实质差别、知识体系差别、面向对象差别、运维人员差别、体制理念差别。谁里只摆放一个架构差别的图解，如下图所示。（具体阐述请参见作者文章《传统运维 VS 互联网运维从哪来到哪去》）。
6、网络大流量事件处置   谁时张驰快步向我走来，看着有些着急：有故障，我们的多个域名打开异常缓慢，网站性能监测频发告警。虽然我干IT工作10余年了，不过当我听到“故障”谁俩字，仍然感觉刺耳敏感。作为运维人，经常要救火，头脑是要冷静，做到胆大心细，行事不妨忙不过不能乱。对于谁种访问故障，我们通常会基于网络架构层次逐个捋顺排查和定位。网站架构通常如下图所示。

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

7、变更经验总结
主要原因是：谁组特殊的ngnix在负载后面，不过由于错误的iptables策略，收到负载请求则不处理丢弃，因此造成超时tcp重传，负载只能再向ngnix分配请求，如此造成访问请求缓慢不稳定。虽然不懂的地方解决，不过我总结指导训如下：
1、尽量避免变更，应保持不可变基础设施。
2、一次变更只做一件事，同时做好变更的记录。
3、条件允许的话，在做变更之前先做好测试、应急回退措施。
4、做变更尤其好有实施者，有复核（配合）人员，有工作互备人员。尤其好能做到相关人员周知。
5、变更尤其好周五之前做，夜晚做。
6、运维自动化的确是把双刃剑，没有标准化、流程化的批量自动化也许是灾难。

8、运维架构体系规划   谁时我突然想起老大的提醒，我应该从架构体系的层面梳见解决当前一锅粥似的一系列不懂的地方。运维架构体系是运维的基础及核心竞争力。利用途径运维体系的构建及完善，使我们的运维做到稳定可靠，准确完备，规范科学。以面向服务、持续交付为核心，从人、事、物、流程谁四个方向把运维体系进行解构，它们彼此互相作用，共同构建了一个完整实用的运维体系。 linux运维工程师是做什么的从忙碌的一天说起