> 文章列表 > 浅谈运维工程师的开发能力的培养

浅谈运维工程师的开发能力的培养

浅谈运维工程师的开发能力的培养

写在前面

本文已获得作者授权,作者的博客地址:https://www.cuiliangblog.cn/
原文链接:浅谈运维工程师的开发能力的培养

浅谈运维工程师的开发能力的培养

一、运维工程师发展路线

1. 传统运维

侧重点是解决具体的问题。要求具备扎实的底层的知识储备,如网络、linux、数据库、硬件设备调试、服务部署等。以及一定的故障处理能力和经验,能够快速解决问题,实施变更。能够处理突发故障,顺利完成服务的部署,变更的实施。

2. 云计算运维

侧重点是开源技术方案的使用,为云服务的稳定提供保证。随着业务不断发展,服务器规模扩大,就需要具备大规模服务器的批量管理能力。要求对开源技术解决方案有一定的掌握,主要面向基础运维平台建设,运维工具的开发,提高运维效率。硬件层面的资产管理。系统层面的管理例如vmware openstack虚拟化,以及docker k8s容器化。应用层面例如prometheus监控,elk日志,集群,数据库等开源服务管理。重点在于广泛使用开源技术保障服务的稳定,为项目的稳定运行提供保障。

3. DevOps

侧重点是开发运维平台,要求较高的开发能力。主要是管理应用的全生命周期,负责自动化运维平台的设计和开发,实现运维标准化、自动化、平台化。例如开发CMDB平台、作业平台、工单系统、告警平台等。以及充当业务开发与业务运维中间人的身份,从中发掘业务瓶颈并推动优化与改进。

4. SRE

侧重点是从业务角度提升运维质量*。负责软件和系统的架构设计,运维流程的优化,让公司服务以及系统运行得更加可靠,更加稳定,扩展性更好,更能有效地利用计算机资源。要求技能包括算法,数据结构,编程能力,网络编程,分布式系统,架构设计,故障排除等能力。SRE重视开发,重视效率,追求自动化,专注于整个软件系统的生命周期管理。
需要明确的一点是DevOps 首先是一种文化,后期逐渐独立成一个职位,而SRE从一开始就明确是一个职位。DevOps更需要开发能力,而SRE更需要知识的广度。DevOps 工程师掌握相关技能之后,也有机会可以发展为 SRE 工程师。 而一位合格 SRE 工程师,在有选择情况下面,我相信不会去转型为 DevOps 工程师。

二、运维开发技能学习路线

浅谈运维工程师的开发能力的培养

三、常见的运维开发项目案例

1. 公有云管理平台

● 项目背景
大型互联网公司出于成本、可靠性等因素,往往会购买多家云厂商产品提供服务。但在日常运维工作中,高频的操作往往也只是查看主机配置信息、当前机器状态、以及资源到期时间、服务器强制重启、CDN资源刷新、COS存储查看、日志下载等操作。

可以根据上述需求,开发一套公有云管理平台。将所有资源列表形式展现出来,配置信息、当前状态、到期时间等关键内容直观展现出来,并使用标签的方式,实现资产的便捷筛选。

只授予开发人员常用操作,例如CDN刷新,日志下载,COS存储查询等操作权限,避免登录云服务器控制台误操作情况发生。

● 项目亮点
使用腾讯云、阿里云、华为云等公有云厂商sdk,实现资产信息的查询等高频操作

使用celery实现信息异步定时更新入库

用户权限管理,开发人员和运维人员权限分离

使用antv-g6实现资产树结构

使用echarts将资产统计信息可视化展示

2. CMDB

● 项目背景
企业中IT资源种类繁多(机房、服务器、存储设备、网络设备、项目业务划分等)且需要频繁更新,传统的excel表格维护更新方式已不能满足需求。此时就需要通过开发资产管理系统,实现资产的自动发现和信息同步更新,保证数据的准确和一致性。除此之外还开放API接口与现有的运维体系结合,为作业系统、工单系统等平台提高IT数据支撑。

● 项目亮点
由于资产的字段,对应关系频繁更改,传统的关系型数据库已无法满足需求。通常采用MongoDB存储数据。使用mongoengine库完成数据库的操作。

使用ansible的API接口调用setup模块抓取服务器硬件信息,支持手动同步和定时同步信息。

也可以使用shell脚本或者go开发exporter,定期向cmdb接口上报服务器信息。

提供动态 Inventory 清单接口,方便ansible调用执行批量化操作。

提供完善的资产信息、模型、对应关系增删改查接口,方便其他工具平台调用。

3. 作业平台

● 项目背景
面对批量管理主机的需求,已有成熟的ansible,以及web工具Tower,但是缺乏现成的API接口,无法与现有的自动化运维平台直接调用。

随着服务器规模增多,存在大量的定时同步、备份、清理等任务脚本。需要集中化管理定时任务,并对任务执行情况一目了然。

当进行服务批量部署、软件包批量更新时,具备批量文件传输的能力。

记录所有通过作业平台页面或者API调用的操作记录,提供任务重试和历史记录查询的功能。

● 项目亮点
将常用自动化操作(例如给开发人员创建普通用户账户设置权限、常见服务部署、配置文件更新等操作)提前编写playbook。当需要执行常用自动化操作时,调用CMDB接口获取动态主机清单,并在前端传入相关变量参数,完成playbook变量替换,使用ansible执行playbook,完成相关的自动化操作。

使用对象存储或者ansible所在服务器本地目录,实现文件上传功能。存放常用shell脚本、需要批量分发的文件,便于ansible调用相关文件执行自动化操作。

开发定时任务管理模块,使用异步多线程执行。支持任务结果查询验证功能,实现定时任务的统一集中化管理。

开放提供API接口,支持传参调用执行批量任务并返回执行结果。

4. 工单系统

● 项目背景
在公司内部,项目上线、配置变更、调整权限等操作,往往都按照运维管理制度,依次由负责人审批,通过后再执行相关具体操作。传统的资源申请基本是通过邮件,存在沟通成本高,消息处理不及时的问题,且出现问题后回溯麻烦。

开发一套工单系统,可以将运维平台各个自动化程序组件相关联打通,可以极大的规范内部管理流程,提升沟通及管理效率。

● 项目亮点
与公司内部邮箱或通讯软件集成,实现每步流程申请人和相关审批人邮件或消息通知。

与钉钉或企业微信的用户列表集成,避免人员流动时频繁手动更新维护数据。

与作业平台集成,当领导完成审批后,直接调用作业平台API,执行一系列自动化的操作。

在前端使用流程图方式展示整个操作的完成流程,以及当前完成进度。

5. 告警平台

● 项目背景
为了保障业务稳定,通常会采用多种监控服务实现告警通知,但通常都存在告警复杂而凌乱,无法将告警信息进行灵活分类,缺乏统一管理的能力。这样就加大了运维人员对告警信息的判断难度,进而无法快速的的定位到根因,也就无法快速的解决问题。

传统的告警配置,告警通知人员/通知组,告警等级在创建告警时已配置,不具备灵活将告警内容通知至值班人员和告警长期未处理,告警严重性等级提升的功能。

● 项目亮点
告警统一收集汇总。将现有的Alertmanager、grafana、kibana、以及其他的脚本告警统一收集展示,方便运维人员清楚知道当前系统存在的问题。并提供历史告警查询功能,便于分析当前容易产生的告警,促使不断优化改进,降低告警产生。

灵活的分配策略。根据不同的应用,选定不同的筛选条件,将条件相结合,让指定的告警通知到特定的人。并于现有的值班系统相结合,使每条告警按不同的告警等级以微信、邮件、短信、电话的方式通知到值班人员和第一负责人。

当告警在指定的时间段内未恢复时,启动告警升级策略。将告警通知至第二负责人,以此类推。

与工单系统集成,自动将告警事件指派给对应负责人,并创建工单提示负责人及时处理故障。

6. 应用发布系统

● 项目背景
应用发布系统使用现有的Jenkins发布平台或者Gitlab CI均可。但是缺乏与现有的运维平台建立连接的能力。理想的应用发布系统应当是当开发人员提交申请单,领导审批完成触发自动更新操作,从发起到结束形成闭环。可以利用Jira、Gitlab的webhook功能,以及Jenkins插件的灵活性,实现应用发布系统与工单系统的紧密结合。为项目的敏捷开发、快速迭代提供运维保障支撑。

● 项目亮点
与工单系统紧密结合。当开发人员完成新功能开发后,只需在工单系统提交新版本上线流程。待领导审批后,执行自动化部署操作。

与Jenkins紧密结合。通过webhook自动化完成分支更改、部署发布流程,减轻人工运维操作工作量。

与CMDB紧密结合。当完成版本发布后,自动更新相关记录。

四、运维平台案例参考

1. 蓝鲸智云平台

https://bk.tencent.com/docs/

2. spug

https://spug.cc/docs/about-spug/

3.CODO

https://github.com/opendevops-cn/opendevops

五、常见运维场景自动化思路

1. 新建资源

浅谈运维工程师的开发能力的培养

2. 发布流程

浅谈运维工程师的开发能力的培养

3. 配置变更

浅谈运维工程师的开发能力的培养

4. 故障处理

浅谈运维工程师的开发能力的培养

六、学习资料视频推荐

1. python后端

python菜鸟教程(适合有一定开发基础,直接查看文档,节省时间)
https://www.runoob.com/python3/python3-tutorial.html

python黑马程序员视频(适合从0开始学习入门)
https://yun.itheima.com/course/542.html

django视频教程(主要学会url view models admin)
https://www.bilibili.com/video/BV1jx41197Qv?p=1

django文章专利(目前已知国内研究django最深入的博主了)
https://pythondjango.cn/django/basic-tutorials

flask教程(学会了django后,学习flask直接参考文档即可)
https://www.cainiaojc.com/flask/

DRF视频教程(学完DRF基础知识后,跟着老师做一个项目,就可以完全掌握了)
https://space.bilibili.com/481846903

request爬虫(根据实际需求,网上现查即可,如果想系统学习,推荐购买书籍)
https://item.jd.com/13527222.html

2. 前端

html css视频教程(黑马的pink前端必须强烈推荐)
https://www.bilibili.com/video/BV14J4114768?p=1

JavaScript视频教程(推荐李南江,自带二倍速的男人)
https://www.bilibili.com/video/BV1rt4y1Q7wo?p=1

jQuery+ajax(了解即可,现在基本都是前后端分离开发)
https://www.bilibili.com/video/BV17W41137jn?p=1

echarts数据可视化(还是推荐黑马的pink)
https://www.bilibili.com/video/BV1v7411R7mp?p=1

vue视频教程(还是建议大家多看官方文档,毕竟国人写的,还是很容易理解)
https://www.bilibili.com/video/BV1Zy4y1K7SH?p=1

vue2 PC端项目实战(适合新人入门,代码并没有高度组件化)
https://www.bilibili.com/video/BV1eh411d7zD?p=1

vue3 手机端项目实战(接近实际项目开发,强烈推荐)
https://www.bilibili.com/video/BV1YK4y1W7k5?p=1

微信小程序(微信小程序入门较为简单,主要参考官方文档即可)
https://www.bilibili.com/video/BV1WP4y137EE

七、运维思考

1. 如何从0开始实现运维自动化

梳理目前手头的工作,你会发现其中有一半的运维工作都存在重复性,或者满足某些特定场景条件下触发,且每次操作的步骤基本相同,存在较少的意外情况发生。那么就对这些常见问题进行分类和梳理,考虑能否将这些工作内容改造成自动化操作。起步初期不一定需要做多么完善的平台出来,可以先着手于解决实际运维工作中的一个个具体的实际小问题,并听取其他同事的意见,帮助他们开发特定场景需求下的自动化工具,积累开发经验。先从最基本的操作自动化做起,逐步拓展到特定场景下的自动化处理,再到最后实现智能化运维。

运维自动化不是一蹴而就的,他是一个漫长的逐步演进的过程。通常都是遵循这样的演变:运维人员手动支撑 => 运维标准规范化 => 运维工具化 => 平台自自动化。

2. 运维自动化与运维标准

要想解决运维自动化的问题,前提是在运维团队内部已形成运维标准化/规范化。试想一下,如果同样的一个nginx服务,由不同的人操作部署。由于每个人操作习惯不同,且没有运维标准,必然会导致服务的部署方式、部署目录、启动用户五花八门。当你想开发一个工具管理所有nginx服务时,你会发现,有半数的工作量是要编写一堆if条件判断,来适配各种各样的环境目录问题。

因此,要想实现运维自动化的首要条件是避免差异性,实现环境的统一。因为团队中每个人的习惯不同,没有规范必将导致服务器配置差异,这将在无形中大大增加了运维的难度。只有实现了运维标准规范化,才能为后续的自动化打下坚实的基础。

但是需要注意的是,在运维标准的实践过程中,标准的制定很容易,但是人为执行起来却很难。因此,在规范制定之时,应该要满足大多数人的风格习惯,制定的规则简明扼要,不要让理解规则成为负担,最后是需要运维团队每个人需要明确规范的目的,让运维规范成为大家的共识。才能让每个人在以后的运维工作严格的按规范去执行、不断的进行优化改进,为自动化运维打下坚实的基础。

3. 运维思路转变

纵观整个IT技术岗位,运维人员应该算是最为“苦逼”的一波人了,没有经历过半夜被故障告警电话吵醒、通宵实施变更的运维职业生涯是不完整的。但是公司的管理者往往有些对技术了解并不深入。无论是出现网站访问缓慢,还是系统各种错误,管理层首先想到的第一件事就是找运维这个“救火员”。从一定意义上讲,保障业务的稳定运行是运维人员的基本岗位职责,但是不排除很多情况下是因为开发人员代码质量低,导致运行出现问题,然而有些开发人员未经自查便得出结论,是系统环境的问题,所以运维充当“背黑锅”是常事。不仅要承担别人犯下的错误,还要拼死拼活地去解决可能非自身原因造成的问题。

但是随着IT规模越来越大、系统越来越复杂,以故障事件驱动的“救火员”,依靠人工检查处理的工作方式,不仅会让自己的工作被动,还效率低下。而且随着最近几年各家公有云厂商产品不断完善,云计算对于运维人员来说,既是机遇,也是挑战。一方面,云计算使得运维门槛越来越低,运维人员不再需要关注机房、硬件、网络、系统这些底层的技术保障,只需要在控制台web页面点点鼠标就能完成日常的运维操作,遇到疑难问题也只需要提交客服工单即可解决,但是只会提交工单的运维又怎么能为企业带来更高的价值呢?

基于以上原因,自动化运维应运而生。自动化运维的基本目标解决的是“能程序完成的事情尽量不要用人去干”,具体来说就是把周期性、重复性、规律性的工作都交给工具去做,最终达到提升运维效率的目的。简单来说,就是运维思路的转变,不再像以往那样仅仅是保证服务的正常稳定运行,出现故障能第一时间修复的这种以事件为驱动的运维工作。而是要让自己的精力从底层简单的日常运维工作中解放出来,做一些更具价值的事,以建设一套完善的自动化的运维体系为目标,充分发挥自己的核心竞争力,毕竟没有哪个开发能比运维更懂运维自动化产品的需求。在运维自动化建设中,每个运维人员即是优秀的产品经理,也是产品的开发者和使用者。

原文链接

浅谈运维工程师的开发能力的培养
https://www.cuiliangblog.cn/detail/article/39