蚊章汇 - Carlos Nunez
type: channel
link: https://linuxcn.bwsl.wang/author/1093/
description: Carlos Nunez
items: DevOps 实践指南

DevOps 实践指南
type: item
date: 2018-10-08T07:22:40+08:00
description: 这些技巧或许对那些想要践行 DevOps 的系统运维和开发者能有所帮助。在去年大概一年的时间里，我注意到对“Devops 实践”感兴趣的开发人员和系统管理员突然有了明显的增加。这样的变化也合理：现在开发者只要花很少的钱，调用一些 API，就能单枪匹马地在一整套分布式基础设施上运行自己的应用，在这个时代，开发和运维的紧密程度前所未有。我看过许多博客和文章介绍很酷的 DevOps 工具和相关思想，但是给那些希望践行 DevOps 的人以指导和建议的内容，我却很少看到。这篇文章的目的就是描述一下如何去实践。我的想法基于 Reddit 上 devops 的一些访谈、聊天和深夜讨论，还有一些随机谈话，一般都发生在享受啤酒和美食的时候。如果你已经开始这样实践，我对你的反馈很感兴趣，请通过我的博客或者 Twitter 联系我，也可以直接在下面评论。我很乐意听到你们的想法和故事。古代的 IT了解历史是搞清楚未来的关键，DevOps 也不例外。想搞清楚 DevOps 运动的普及和流行，去了解一下上世纪 90 年代后期和 21 世纪前十年 IT 的情况会有帮助。这是我的经验。我的第一份工作是在一家大型跨国金融服务公司做 Windows 系统管理员。当时给计算资源扩容需要给 Dell 打电话（或者像我们公司那样打给 CDW），并下一个价值数十万美元的订单，包含服务器、网络设备、电缆和软件，所有这些都要运到生产或线下的数据中心去。虽然 VMware 仍在尝试说服企业使用虚拟机运行他们的“性能敏感”型程序是更划算的，但是包括我们在内的很多公司都还是愿意使用他们的物理机运行应用。在我们技术部门，有一个专门做数据中心工程和运营的团队，他们的工作包括价格谈判，让荒唐的月租能够降一点点，还包括保证我们的系统能够正常冷却（如果设备太多，这个事情的难度会呈指数增长）。如果这个团队足够幸运足够有钱，境外数据中心的工作人员对我们所有的服务器型号又都有足够的了解，就能避免在盘后交易中不小心搞错东西。那时候亚马逊 AWS 和 Rackspace 逐渐开始加速扩张，但还远远没到临界规模。当时我们还有专门的团队来保证硬件上运行着的操作系统和软件能够按照预期工作。这些工程师负责设计可靠的架构以方便给系统打补丁、监控和报警，还要定义 基础镜像 gold image 的内容。这些大都是通过很多手工实验完成的，很多手工实验是为了编写一个 运行说明书 runbook 来描述要做的事情，并确保按照它执行后的结果确实在预期内。在我们这么大的组织里，这样做很重要，因为一线和二线的技术支持都是境外的，而他们的培训内容只覆盖到了这些运行说明而已。（这是我职业生涯前三年的世界。我那时候的梦想是成为制定最高标准的人！）软件发布则完全是另外一头怪兽。无可否认，我在这方面并没有积累太多经验。但是，从我收集的故事（和最近的经历）来看，当时大部分软件开发的日常大概是这样：开发人员按照技术和功能需求来编写代码，这些需求来自于业务分析人员的会议，但是会议并没有邀请开发人员参加。开发人员可以选择为他们的代码编写单元测试，以确保在代码里没有任何明显的疯狂行为，比如除以 0 但不抛出异常。然后开发者会把他们的代码标记为 “Ready for QA”（准备好了接受测试），质量保障的成员会把这个版本的代码发布到他们自己的环境中，这个环境和生产环境可能相似，也可能不，甚至和开发环境相比也不一定相似。故障会在几天或者几个星期内反馈到开发人员那里，这个时长取决于其它业务活动和优先事项。虽然系统管理员和开发人员经常有不一致的意见，但是对“变更管理”却一致痛恨。变更管理由高度规范的（就我当时的雇主而言）和非常必要的规则和程序组成，用来管理一家公司应该什么时候做技术变更，以及如何做。很多公司都按照 ITIL 来操作，简单的说，ITIL 问了很多和事情发生的原因、时间、地点和方式相关的问题，而且提供了一个过程，对产生最终答案的决定做审计跟踪。你可能从我的简短历史课上了解到，当时 IT 的很多很多事情都是手工完成的。这导致了很多错误。错误又导致了很多财产损失。变更管理的工作就是尽量减少这些损失，它常常以这样的形式出现：不管变更的影响和规模大小，每两周才能发布部署一次。周五下午 4 点到周一早上 5 点 59 分这段时间，需要排队等候发布窗口。（讽刺的是，这种流程导致了更多错误，通常还是更严重的那种错误）DevOps 不是专家团你可能在想 “Carlos 你在讲啥啊，什么时候才能说到 Ansible playbooks？”，我喜欢 Ansible，但是请稍等 —— 下面这些很重要。你有没有过被分配到需要跟 DevOps 小组打交道的项目？你有没有依赖过“配置管理”或者“持续集成/持续交付”小组来保证业务流水线设置正确？你有没有在代码开发完…