开发和运维可以说是一体两面，正如对于一个司机而言，如果只会开车而不具备车的维修保养知识，那这样的司机在市场上是吃不开的。即使是为自己开车，这样的私家车主也会因此而付出额外的经济代价，更别提可能带来的安全问题。

简单的讲，缺乏运维知识和技能的开发者会很快无法适应快速发展地软件行业，被迫早早退休，在没有实现财务自由的前提下。

但鉴于我观察到这一非常明显的认识却并没有被大多数人放在心上，加之受“软件在吞噬世界”这一趋势感召而转行的各路青壮年缺乏必要的指导，我觉得有必要把这个话题说一说。

做好开发需要运维知识

在很多不入流的开发者心目中，所谓完工仅限于“功能的完成”。在这里，我不会去讨论功能正确性的问题，因为它不是本文的主旨，单就运维知识展开说明。

缺乏运维知识的开发者所谓的完工常常表现为：

• 环境参数硬编码，导致根本无法部署到生产环境。比如：IP 或端口写死。
• 认为外部资源无限量供应，本地手工测试无法暴露问题，一旦上线，各类泄露和溢出不断。
• 缺乏统一的 log 指导，线上问题无法追踪，因为要么没有，要么用 printf 直接达到终端，根本没有存档。
• 安全意识不到位，对于密码随意处理。这里单举两个例子：
  • 代码直接使用明文作为数据库连接的密码
  • 用户的密码直接以明文存储在数据库中

如果要继续写，这个列表还可以更长，但限于篇幅，就此打住。这些表象，究其根源在于这些开发者的心目中根本就没有“运维”这个词。在他们觉得这是别人的事情，压根就不会去考虑！

很遗憾，这种思维模式已经不能适应时代的要求，在 DevOps 盛行的今天，如果还持这一念头，那我劝你趁早转行。

微服务大趋势下的要求

不管你喜不喜欢，微服务已经成为开发者的口头禅。对于面试官，我建议当一个应试者在你面前对微服务侃侃而谈之时，考考他的运维知识。这将充分的区分开优秀的微服务开发者和南郭先生。

透过当下热闹的微服务浪潮的表面，作为架构师或者开发者，更应该看到它的里面：对运维能力要求的大幅提高。缺乏合格的运维能力去实施微服务，不仅不能解决老问题，而且还会带来新问题：

• 相互依赖的服务间如何保持高效开发的同时还能在集成测试时不会出现扯皮？
• 如何处理服务升级，尤其这个服务被多个其他服务同时使用的时候？
• 为了测试整个系统，怎样有效地搭建测试环境？
• 在分布式的环境下，如何快速定位“问题服务”？

同样的，潜在的问题远远不止这么多，但如果脑子中没有“运维”这根弦，可能事到临头了才会懊恼。可以这样说，如果运维能力不达标，贸然决定上微服务，就两个字：找死。

自动化的必由之路

软件开发不比搬砖，不是“人多力量大”。有自动化思维的开发者，其价值要远远高于那些普通的开发人员，其中差距之大可以比得上人和动物的区别：人会制造工具。

可以说，具备自动化思维是一名开发者成熟的标志。

对于缺乏运维技能的开发者，连操作系统的命令都掌握不全，有怎么能指望他能熟练运用 Shell 或 Python 这里工具去做更高级的事情？而且，随着开发和运行环境的越来越复杂，仅凭人力已经远远无法有效地支撑开发者的日常工作，此时只能求助于自动化手段去解决。

最简单的例子就是：项目的依赖管理。时光倒退 20 年，人工管理项目依赖并不新鲜。放在眼下，假如你的项目（以 Java 项目为例）还是这样来搞，作为老板，你真是要好好检讨一下是不是工资给少了！

更好地替老板和用户省钱

这里专门列出这一点恰恰是因为很多开发者脑子里就没有这一概念，就好像钱是天上掉下来的一样。而且觉得这不是他该操心的内容，大不了换家公司继续拿着高薪。

的确，要求员工替老板省钱是高了一点。但，会替老板和用户省钱，在不损失质量的前提下，这样的开发者肯定会被青睐。只要这一习惯继续保持，人生肯定混的也不会太差。正所谓：助人者人助之，迟早会遇到贵人。

回到正题，为何说拥有运维技能可以更好的省钱？这里举个例子：在当前各类云横行，前后台分离的大趋势下，怎样才能比较好的选择一个部署架构，使得用户体验不错，而且应用运行也还不错？

这里也不卖关子了，简单说一下我们的做法（这很大程度上归功于我们有一个优秀的运维小伙），以阿里云为例：

• 前端：OSS + CDN
• 后端：ECS
• 数据库：RDS

如果缺乏运维经验，估计会很大概率上选择自己购买 ECS，其余的自己搭建。比如，对于前端，在买来的 ECS 上面部署 Nginx，然后把前端代码部署上去。相比起 OSS，其价格差距之大可以从阿里云的价格表上看出来。而且，为了达到高可用，还得做一堆屁事。配上 CDN，其访问体验要更好。

有人说，我可以和后台部署在一起呀。没错，你甚至可以将所有的东西都部署在一台 ECS 上，但这样的可靠性可想而知，已经不是我上面那个“应用运行还不错”的前提了。

单就价格来说，上面的做法就比“自己动手丰衣足食”要有更大的优势了，这里还没有算每年节约下来的人力成本！

我的推荐

可以说，这里也暴露了本文的另一个目的：推荐拆叔的《敏捷团队工程实战课 之 程序员(Dev)的运维(Ops)课》。看到这，你可能心里在嘀咕：软文。

或许吧，但我从来只推荐值得推荐的东西。之所以我觉得拆叔的课对于开发者有帮助并且值得上，主要出于以下观点。

知易行难

DevOps 的理念在这几年其实不新鲜了，而且理解起来也没有什么难度。但由于个人技能的缺乏，导致好的理念难以落地。这门课恰好可以补上这个缺失，让开发者了解需要了解的知识和工具，开启运维之路。

厘清思路

对于大多数开发者来讲，运维其实是个朦胧的概念，似懂非懂。拆叔在这门课上会有一个对比，将 Dev 中的工具链和 Ops 中的工具链一一对应，单就这一点就让人大开眼界。这个对比也曾出现在我去年组织的敏捷之旅上，同样效果不错。

见识高水平的工作环境

有人经常说：贫穷限制了人的想象力，但我觉得真正限制人想象力的是：见识。没有见过高水平的工作环境和场景，很多人根本不会想到还有这样的工作方式、方法和工具。见识一下，开阔你的思路，再考虑一下说“不可能”。

拆叔脱口秀

拆叔是一个有趣的人，这不是我一个人的观点。在课堂上，你可以有充分的时间去体会，同时在这个过程中感受到他满满的正能量和获得一些你意想不到的东西。

如果你还依旧对此有所怀疑，可以进入上面链接看看其他人的推荐之辞。

友情提醒

当然，为了客观起见，我得说说这门课的一个缺憾：过于集中在个人技能，缺乏对于运维体系的整体介绍。这并非我一家之见，并且就此我也跟拆叔有过讨论。他的答复是：这恰恰是他有意为之，因为市面上讲理论的太多了，专门针对开发者的运维技能实操的反而太少。

好吧，我写个大大的“服”！

不过好消息是，鉴于这类意见太多，拆叔会考虑在未来的课程中加上这些内容，让我们拭目以待吧。

或许，未来还会出现面向架构师的运维课也不一定哦。