你好，我是你的运维课老师牧客，你也可以称呼我为 Jeson，我在运维领域深耕 10 余年，现在是一家知名互联网公司架构师。我曾就职于大型互联网公司阿里巴巴、大型国企中国体彩等，先后担任运维专家、SRE 负责人、运维架构师等核心岗位。曾经主导开源国内第一个基于 Ansible2.4 实现的完整运维自动化项目；曾带领 SRE、运维开发、DBA 三个团队出色重构近千级别主机的运维架构。
运维行业发展
随着互联网行业的快速发展，对运维工程师的要求也越来越高，我根据自己的经验和体会将运维行业划分为三个时代。
第一个时代算是“工业”时代，随着早期开源社区的增加及各类软件推广度的提高，使得开源软件在企业的应用逐步增加，企业可以以更小的成本快速搭建起一整套完整的、可应用的服务底层架构。而技术人员对于开源软件的驾驭能力有限，如对 Linux、MySQL 等开源软件的管理，这些都需要成熟的技术人员来整体负责，于是运维工程师就成为企业大规模用人需求。
第二个时代算是“蒸汽机”时代，随着近十年互联网广泛普及、大数据时代的到来，各类技术企业规模逐步壮大，对系统架构也提出了越来越高的要求，系统的承载力、自动化能力等都需要同步提高，运维工程师就需要具备更高效、更成熟的技术能力。就像汽车淘汰马车一样，大量的初级运维人员在这个阶段被淘汰。
第三个时代来到“航天”时代，当前互联网竞争已经进入“下半场”，公司需要靠“成本降低”和“效率提高”来实现“精耕细作”，这也就对运维人员提出了更高的要求，我们会感受到新业务开发上线周期要求更短，容器 + K8S、SDN 等技术的不断成熟也使得软件允许脱离固定环境依赖，Devops 类型人才或高级应用运维开发成为当前运维工程师所必须要发展的方向。在这个时代可以说运维工程师除了要把飞船发射出去，还要考虑如何实现载人、回收、空间对接等功能。
技术壁垒突破
基于以上的行业现状，技术过硬的运维在未来会更加吃香，而一般的运维工作则会被云平台取代，然而我们会发现大多数运维人工作机械、缺乏开发经验、技术难以沉淀、自动化转型困难。
面对这种困境，如何才能突破自己的技术壁垒呢？这就需要我们认清楚未来运维的发展方向在哪里，我们可以从以下这 3 个方向来寻找答案。
运维平台缔造者；
高级应用运维工程师；
人人皆可运维。
理清了未来的发展方向，就需要在日常工作中有针对性地细化我们的运维高效能力以适应未来发展需求；放眼未来，立足当下。
高效运维能力
想要提升高效运维能力，我们就需要从运维流水线能力、故障处理能力、资源精细化三方面入手。
运维流水线能力
Devops 打通各个核心环节，逐步集成配置管理、A/B 测试、灰度发布等更多环节。
运维部署要求秒级交付能力，减少环境依赖，应用更加轻量化、架构去中心化、服务 set 化等。
故障处理能力
故障处理能力则更是和时间赛跑，我们不仅要求定位问题准，也要求处理问题更加及时，如：核心的网络交换机、数据库切换更是需要作到秒级容灾。
资源精细化
企业要求动态感知业务使用资源状态，分钟级扩缩容。
要求海量资源信息自动化管理。
甚至要求融入 AI 的分析业务对于资源实际使用情况。
正因为这种自动化平台高效能力的提升，我们可以感受到传统的运维模式正在逐渐消亡，企业中人人皆可运维、而专职运维人员则需要让运维工作更加高效。
成功经验分享
而我有幸见证并参与了整个运维行业的发展，从不会 Shell 命令到开源多个运维自动化工程，从运维菜鸟到带领团队完整重构一个中型企业的运维架构，从求职小公司被拒到在 BAT 一线企业担任核心要职。
之所以能够实现质的飞越，在工作中有两个案例及思考不得不和你分享，也希望你能够从中得到启发并能够帮助到你。
紧跟趋势、寻求资源、快速补足技术短板
你是否 1 天内查收多达 1 万多条报警？你是否 1 周内都需要做固定的业务变更？你是否还需周期性的进行业务服务巡检？
曾经的我是一家国内大型视频公司的运维工程师，我的例行特点就是每天需要处理如上所述的这些需求，拿报警处理来说，由于当时我们没有完备的自动化平台，收到一条报警就需要去排查，如果是硬件故障就录入保障系统，如果是磁盘快满了就需要手动清理磁盘。
这种处理模式在一段时间内可以提高动手能力，处理同一件事情的速度更快，但远远不能满足“高效性”和“快捷性”的要求，当时我就常问自己，如果想提高工作能力，实现职业发展，需要在哪些方面进行提高？这个行业未来的趋势如何？机会点又在哪里？
运维这个行业的趋势在哪里？
当时广为流传的概念就是“自动化”“持续集成”“虚拟化”，通过这些概念可以看到，企业的用人趋势是要增强运维高效性，提高成本利用率。
我的痛点是什么？结合趋势如何发展自己？
如何提高运维效率？当时首选的方式是通过开源工具来提高，如通过 rsyslog 来进行集中日志收集、通过 Jenkins 来进行 CI\CD 等等，这种方式虽然能够提高部分效率，但当大型企业需要满足自身架构特性，或需要解决性能、安全性问题的时候却难以满足，只能通过再次开发实现，而“缺乏开发经验”就成为我需要攻克的难题。
基于此，我就想尽快提高自己的开发能力，由于工作时间饱和，挤出的业余学习时间不多，而且大多停留在理论学习上，“纸上得来终觉浅”，感觉自己的开发能力上升的还是比较缓慢，当时恰巧公司出台了鼓励内部转岗的政策，我便快速和开发团队融合，得到了全身心去学习、有了一个实践业务开发的机会，这让我的开发能力快速的提高，从运维到开发的转型，成为了职业道路的垫脚石，让自己在后续的职业发展中站的更高、看的更远。
看到潜在价值和机会，积极寻求他人经验，“博观而约取”
有人可能会认为运维就是作做一些边边角角的事情或难以承担重任，以我经验来看则认为不是，企业高层或老板很需要得力的运维干将。记得 18 年我从阿里离职后在一家互联网公司担任架构师，这家公司的如下两点对我产生吸引力：
运维所能创造的价值
刚入职时，这家公司原有的运维团队核心成员离职，技术人员无法掌控整套运维平台，导致每周业务高峰期经常出现 2~3 次核心业务故障，整体服务可靠性低于 90%，服务的稳定性无法保障导致公司业务发展缓慢，而研发人员不懂运维或底层架构的实现，所以急需有人能够支撑起来整套业务运维系统及运维工作。
公司的系统规模
公司约 1000 多个实例，涵盖虚拟化、容器化、自动化及整套业务应用服务。这样的一个业务规模让我有了一个施展能力的机会。
工作的 1 年中，我负责主导分析公司架构上的问题并提出改进建议，提出相关改进方案（如：混合云架构改造、核心网络规划、4~7 层 LB 负载均衡改造升级、数据库迁移改造等)，并重构多套运维平台，如：CI\CD 平台、监控、CMDB 等，公司的服务可用性也得到一个很大改善和提升。
现在回想起来，我认为能帮助我出色完成工作很重要的一个原因是自己经常去寻求他人的经验，如在处理公司服务问题时，我经常会询问之前的运维和研发同学，了解发现的现象、处理方式、了解他们的排查思路，然后在自己拆选分析如果下一次问题再复现，我该如何尽快分析到问题根源。
我也会经常逛一些博客或者论坛，或者干脆自己定期召集一群对技术感兴趣的小伙伴，就工作中出现的某一个问题进行探讨和研究，通过别人的工作经验，“博观而约取”，进一步完善自己的知识体系，让我处理相关工作起来更加有效，避免踩别人踩过的坑，也避免走更多的弯路。
厚积而薄发
授人以鱼，不如授人以渔。面对行业的快速发展和运维人的迷茫，我决定和拉勾教育合作推出这门专栏课。
课程设计紧密贴合工作场景
本课程将模拟一个运维工程师所需要处理的主要工作内容，全方位地介绍每一个工作模块中所包含的内容及相互之间的联系。
一个合格的运维所需要承担 7 大块核心工作：“部署”“服务运维”“割接”“故障排除”“监控”“安全防护”“方案设计”，本课程将围绕这 7 场景依次展开，让你所学习知识的更加贴近于工作场景。
课程具有系统性和整体性，而且融合了实战经验
区别于大部分技术课程，本课程不是围绕 1 个技术点逐步开展，而是围绕如何提高整体运维能力去设计。
除了必备基础能力外，一个运维高手需要掌握必要的运维技巧、有丰富的经验及自动化的开发能力，本课程中我收集了自己及身边优秀运维大咖的经验分享及工作技巧，让你在学习完整套课程后，能实质的提升整体运维能力。
课程紧跟技术前沿，具有一定的前瞻性
本课程不局限于介绍具体的技术案例、方法，而是会通过独立“技术趋势”课时介绍与运维技术发展息息相关的行业趋势，让你了解到运维技术未来走向，进而进行更合理的职业生涯规划。
我将在课程中对运维工作经验进行沉淀和提炼，通过学习本课程，你可以不用通过海量的论坛搜索，也不用花费大量精力寻找有运维经验朋友的帮助，更不用因为一些不知道如何处理的运维问题而发愁。因为，课程中提到的问题和案例是普适性，也是广泛性的，经验分享会让你能快速了解到“有效提高运维技能”的方法和经验，通过本课程的学习，让你可以“未雨绸缪”“事半功倍”。
如果你刚刚入行想要寻求更高的职业发展，如果你希望掌握核心的运维能力，就让我们一起开启学习之旅吧。
精选评论
*毅：
Jeson老师，有问题多多指教啊，要有案例demo更好。
编辑回复：
随着课程内容的深入，后面的案例会很丰富的，一定要自己课后多复习多练习。
**8161：
作为一个运维老兵 从游戏运维 转型监控运维 转型IDC ，从单兵作战到团队作案，从以人为主到平台为主，从物理服务器到docker，从window到Linux，从cmd到python3，深感行业变化
sunnyzhang：
留言分享下
**怡：
支持！
2945
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
