发布怪兽DevOps是怎么作妖的——浅析DevOps过程

什么叫DevOps

        DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

        DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

为何要引入DevOps：

        1、使用敏捷或其他软件开发过程与方法

        2、业务负责人要求加快产品交付的速率

        3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍

        4、数据中心自动化技术和配置管理工具的普及

        5、有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

DevOps对应用程序发布的影响

        在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下 ：

（1）减少变更范围

        与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。

（2）加强发布协调

        靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

（3）自动化

        强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

        与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）

DevOps技术的应用和发展

        微服务目前仍然是DevOps技术的主要应用领域，微服务将单块应用系统切割为多个简单独立的应用。从技术上说，这是通过工具把应用程序的内部复杂度转化为外部复杂度，需要一系列工具支撑微服务本身以及服务之间的通信。从组织上说，微服务团队要满足“快速发布，独立部署”的能力，则必须具备DevOps的工作方式。

        如何拆解微服务一直是微服务技术应用的最大难点之一，领域驱动设计是比较理想的微服务拆解方法论。社会化代码分析帮助团队通过更精确的数据找到更加合适的拆分点。CodeScene是一个在线服务，它能帮助识别出热点和复杂且难以维护的子系统，通过分析分布式子系统在时间上的耦合发现子系统之间的耦合。此外，它还能帮你认识组织中的康威定律，这会大大降低微服务解耦的难度。

        此外，微服务系统本质上是一个分布式系统，分布式系统之间的通信一直是很重要的问题。本期介绍的 Kafka Streams 和 OpenTracing 就是这类技术的条目。Kafka作为一个成熟的分布式消息系统已经被广泛采用，而Kafka Streams则将最佳实践以“库”的方式呈现给开发人员，使得操作Kafka更加自然和简单。而OpenTracing则弥补了跨越多个微服务之间请求追踪的空白。

        另一方面，无服务器风格的架构（Serverless architecture）把DevOps技术在微服务领域的应用推向极致。当应用程序执行环境的管理被新的编程模型和平台取代后，团队的交付生产率得到了进一步的提升。一方面它免去了很多环境管理的工作，包括设备、网络、主机以及对应的软件和配置工作，使得软件运行时环境更加稳定。另一方面，它大大降低了团队采用DevOps的技术门槛。

然而，端到端交付以及微服务中的函数管理问题日渐突出。尽管AWS API gateway和AWS Lambda几乎成了Serverless架构的代名词，但这二者结合的开发者体验并不佳。于是出现了Serverless framework和CLAUDIA这样的管理工具。

        AWS Lambda带来的优势也深深影响了企业级应用领域，Apache OpenWhisk就是企业级无服务器领域的选择之一，它使得企业级应用也可以采用无服务器风格的架构构建应用程序。

在微服务端到端交付流程上，Netflix开源了自家的Spinnaker，Netflix作为微服务实践的先锋，不断推出新的开源工具来弥补社区中微服务技术和最佳实践的缺失。而Spring Cloud则为开发者提供了一系列工具，以便他们在所熟悉的Spring技术栈下使用这些服务协调技术(coordination techniques)，如服务发现、负载均衡、熔断和健康检查。

        而在微服务的安全上，最常见的需求之一 是通过身份验证和授权功能来保护服务或API。这部分功能往往是最重要且不断重复构造的。而Keycloak就是一个开源的身份和访问管理解决方案，用于确保应用程序或微服务的安全。且几乎不需要编写代码，开箱即用。它支持单点登录，社交网络登录和标准协议登录(如OpenID Connect，OAuth2和SAML等)。

安全成为推动DevOps全面发展的重要力量

        安全是DevOps永远绕不开的话题，也往往是新技术在传统行业（例如金融和电信）应用中的最大阻碍。一方面，组织结构的转型迫使企业要打破原先的部门墙，这意味着很多原先的控制流程不再适用。另一方面，由于大量的DevOps技术来源于开源社区，缺乏强大技术实力的企业在应用相关技术时不免会有所担忧。

        从代码中解耦秘密信息的管理则让我们避开了一些开发过程中可能会产生的安全隐患。采用git-crypt这样的工具可以帮我们保证在开发的过程中源代码内部的信息安全。而采用HashiCorp Vault则提供了脱离应用程序代码的秘密信息存储机制，使得应用在运行过程中的秘密得到了有效保护。

        Linux Security Module则一直在技术雷达的“采用”区域，通过SELinux和AppArmor这样的LSM兼容帮助团队评估谁可以访问共享主机上的哪些资源(包括其中 的服务)。这种保守的访问管理方法将帮助团队在其SDLC流程中建立更好的安全性。以往这是Ops团队需要考虑的问题，而对DevOps的团队来说，这是每一个人的事情。

        “合规性即代码”（Compliance as Code）是继“基础设施即代码”，“流水线即代码”之后的又一种自动化尝试。InSpec作为合规性即代码的提出者和实现者，通过自动化手段确保服务器在部署后的运维生命周期中依然保持安全与合规。它所带来的意义在于将规范制度代码化，得到了确定性的结果和解释。

        在不远的将来，不难想象人们所面对的法律和法规规定不再是一堆会导致歧义的语言文字条目，而是一组由自动化测试构成的测试环境。

        安全性和易用性往往被认为是鱼与熊掌不可兼得的两个方面。在DevOps之前，团队吞吐量和系统稳定性指标曾经也面临这样的境遇，然而DevOps使得二者可以兼得。同样我也有信心看到在未来DevOps的领域里，更多易用且安全的工具将会不断出现。在降低DevOps所带来的安全风险的同时，也提升团队开发过程的顺畅性和用户便利性。

        以上就是柳猫初识DevOps的一些认知和感受，有失偏颇，还请多多指教。