.. _think_devops: ================== 思考DevOps ================== DevOps，即 ``Development and Operation`` 的组合，不再把开发和运维割裂开来，从最初的软件开发到最终的交付运行，通过自动化工具结合管理流程，实现完整的闭环。 在 :ref:`devops` 中，不仅仅是技术和工具，更多的是日常开发和运维工作中的思考。也许最初只是一个模糊的想法，但是我相信随着不断打磨，就像一块河床上的石头，最终会露出美玉的光泽。 请阅读一下一篇引人思考的文章 `如何部署软件 - 让你团队的部署像地狱一样无聊且毫无压力 `_ : - 好的测试（不是快的测试） - 使用Feature Flag - 通过开关来启用新功能 - 可查验的正确的部署 - 部署的每一步都能够检查验证（自动），通过监控和自动测试工具来实现验证 - 金丝雀和灰度验证 - 代码管理：分支、评审，然后采用微小迭代的分支进行部署测试（金丝雀、灰度） - 合并到master的代码必须是完整测试和验证的代码 - 蓝绿部署 - 审计日志（跟踪问题并可以回滚到任何节点） - 禁止手工变更 - 通过版本管理和自动部署实现变更（可以是Puppet、Ansible这样的配置管理工具，也可以是Docker纯容器的微服务部署） - 在 `AWS内部十条军规 `_ 提到一个观点：判断自动化做的是不是到位，可以思考一下你是不是还需要使用SSH登陆到某台服务器进行运维操作？如果答案是 yes，说明你的自动化做得还不够好。 - 度量指数 - 通过日志实时采集和分析来实现部署评估，设置阀值在误码率达到一定阀值后自动回滚或停止发布 .. note:: 蓝绿部署：蓝意味着在线的生产环境，绿代表空闲的生产环境。 DevOps的关键 ================ - 提供可重用的基础组件 不要重复开发功能类似只是换一种语言、平台实现的大而全的工具平台。 大公司确实有充足的资金和人力来不断推到重建系统，不过我感觉很多系统其实是重复的功能实现，而且由于功能面向特定流程定制，无法作为基础组件复用。每换一批人就重复造出功能几乎一样的平台，虽然投入了大量的资源倒是收益有限。 作为云计算，应该提供的是基础的组件，这样用户可以用这些组件来构建自己的业务。你应该把基础做得更稳定、更具有伸缩性、性能更强且冗灾鲁棒。 - 自动化 想办法构建一个能够定制的自动化平台，不管是Ansible、Puppet还是容器技术。虽然有些故障异常判断还需要依赖人的经验和知识，但是经验和知识需要转化成自动化的监控和异常自动处理程序，来代替人工完成海量服务器的自动运维。 现代的运维人员实际上是开发自动运维工具的开发人员，每发现一个新的未被自动解决的故障类型就应该扩展工具在未来自动发现和解决此类问题。所以，理论上SSH的操作会越来越少。 - API一旦上线无法更改 API的任何改动会影响到用户已有项目，所以就如同操作系统开发一样，真正的好的开发实际上就是定义数据结构。 - 监控资源使用 云计算提供给用户的是基础资源，用户的业务千变万化，使用的方法也往往出人意料。所以，必须有充分完善的监控来了解资源使用，合理改进平台。 - 从产品的整个生命周期都实现安全 安全不是事后检查，而是和质量一样，是从产品的设计制造开始的。从软件开始设计，安全就必须贯穿始终，确保代码、部署的安全，否则云计算平台可能存在潜在的安全漏洞。 - 数据加密 向用户提供自定义加密密钥，实现数据中心服务器端数据加密，这是保障云计算安全的关键。