DevOps：是全栈必备的一把双刃剑
本帖最后由 adminlily 于 2018-10-17 16:56 编辑作为一名全栈工程师，不仅是一个研发多面手，而且必须要关注产品的最终交付，以及线上服务的稳定运行。工具化使开发、交付、运维紧密地联系在一起，于是DevOps 逐渐成为了全栈们手中的利器，但由于DevOps的复杂性，如果没有科学的人员、流程与工具相配合，DevOps根本无从谈起，因此，DevOps 更是一柄双刃剑。
1什么是DevOps呢？
先看一下wiki百科给出的定义：
DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.简单地说，DevOps是一种开发、测试、运营、维护部门之间沟通、协作与整合的软件过程、方法与系统。
DevOps是一种高度强调人与人间互动的工作方式，不能先入为主地认为参与者了解某方面技能，在完成高频率部署的同时，提高生产环境的可靠稳定和安全行。
DevOps能够为团队提供一种极具凝聚力的文化氛围，DevOps不光是一个方法理念，而且是一个有力的技术手段，人员、文化、流程与工具这几大要素在DevOps中同样重要。
2、为什么DevOps姗姗来迟？
DevOps 的概念在2009年就诞生了，但没有相关的技术支持，只是出现在教科书和论文里。然而，近年来所谓DevOps的最佳实践逐渐越来越多，原因何在？
[*]云服务的普遍使用，各种云服务成为IT基础设施中不可分隔的一部分。运维有一个很重要的概念就是Infrastructure as code。
[*]容器技术开始成熟，特别是docker技术的大行其道。容器 Container是用来存储和组织其他对象的对象。Docker是一个开源的应用容器引擎。
[*]微服务架构技术的广泛使用。
[*]微服务 MicroService是指一个单纯的小型有意义的功能。
微服务，是支撑DevOps方法的手段，传统开发是在一个服务器里面，把各种元素装在一起组合成一个程序，但微服务是每一个服务是一个单独的单元，可以部署在不同的服务器上，通过SOA的方法，把它连接起来，再提供整个功能。
微服务是由一个个团队组成，每团队有自己的服务，做好后，可以独立的进行测试、开发、部署，然后整个应用组合到一起。张侠表示，开发运维一体化、微服务和Container是同等的，把它们组合起来，加上云的手段才成为可能。
敏捷开发流程的深入人心。
诸如Scrum, Agile, Kanban等敏捷方式被团队广泛使用，TDD、BDD、DDD这些测试驱动设计、行为驱动设计、域驱动设计等设计方式的采纳，CI和CD这些持续集成和持续部署等方式的实施，这些都是对DevOps的强烈需求。
3、DevOps中的技术栈与工具链
在全栈眼中，Everything is Code，所以DevOps 是通过技术工具链完成持续集成、持续交付、用户反馈和系统优化的整合，实现跨团队的无缝协作。
DevOps 中涉及的技术栈与工具链如下：
[*]DevOps 流程门户： 这是统一操作的web网站，主要是进度看板，Sprint周期等。本着拿来主义，在一定条件下，可以采用类似Trello，worktile等工具代替。
[*]身份及访问管理： 用户权限管理的重要组成，可以采用RABC的方式实现，也可以与LDAP服务对接
[*]产品管理： 产品的需求，定义，依赖，推广等产品线的全面管理，confluence 可能是个不错的选择，禅道也可以满足一部分的功能
[*]配置管理： 提高产品的配置维护能力，zookeeper 大概是不二之选。
[*]持续集成： 提供持续集成任务调度和执行的能力，Jenkins的用武之地，提供产品和组件自动编译、打包和部署的能力，支持编译和部署的流程编制，进度跟踪和日志查看
[*]环境管理： 提供资源配给和负载均衡的能力，需要配合云服务的资源管理能力。初级的负载均衡可以选择nginx或者Haproxy，生产环境的入口最好采用云服务的SLB负载均衡，以便简单地解决HA的问题。资源的调度采用云的弹性能力，辅助脚本实现。同时，微服务的容器化（docker）管理需要特别关注。
[*]质量反馈： 提供产品的质量管理和监控能力，包括测试用例，缺陷跟踪和质量监控。Jira 是个不错的选择，其他的开源工具例如禅道，bugzila，mantis等等，因团队而异。
[*]版本控制： 代码库的创建和维护，分支管理等。Git 几乎是行业的标准，可以自建Git仓库的服务器，也可以使用github 或者bitbucket这样的第三方服务。
[*]自动化测试： 包括客户端与服务器端的自动化测试框架，例如Appium，Selenium 以及各种Mock技术和xUnit
[*]文档管理：各种开发、运维、部署文档的统一管理，同样最好放到git上，同时指出文档的自动化生成
[*]运营管理：这就是传说中的OAM 中心，这是广义的运营，其中还包括运维的部分。OAM 不但提供了业务系统的运营操作，还提供了面向运维的统一Monitor，alarm，fault handling等能力，以及产品的资源使用和运行状况等，涉及的技术很多，尽量采用云监控＋脚本的方式，规模较小时可以尝zZabbix 实现部分功能。
[*]沟通管理： 敏捷的一个原则就是沟通优于文档，IM是团队必备，微信和QQ可以满足大部分的需求，但是Slack 因为其强大的web hook 功能显得更加出色。
4、DevOps 的双刃剑
DevOps 的成功与技术、流程和组织的全面支撑是密不可分的。技术栈和工具链只是DevOps的一个前提和基础，技术方面的实践相对容易，流程较难，组织变革最为艰难。DevOps还是以工程实践为主，管理实践这块，像Scrum成体系的还比较少。DevOps玩得好，可以提高团队的生产力。若是玩不好，可能还不如传统的生产模式有效率。
狭义上看，DevOps主要困难点在于开发和运维是两种完全不同性质的技术工作。很多开发的同事，看着运维人员整天就是玩几个工具，写几个脚本，觉得蛮简单，实际上，很多东西要在生产环境下快速稳定应用，并没有看上去那么容易。生产系统少出问题（软件本身bug除外）是运维的绩效，多实现业务需求是开发的绩效，这一少一多，体现了两种技术角色的根本性区别。
业务部门压力往往导致技术部门的任务主要是求“快”，在这种情况下，DevOps必然失衡，因为只追求快，就不需要ops了，只需要dev加班加点即可，不重视ops，结果必然是可悲的，往往业务上线后鸡飞狗跳，各种问题不断。在激烈竞争环境中，出几次事故就可能对产品形象的伤害很大。
对全栈来说，业务初期到底要不要考虑高可用？从Dev角度看，简洁明快的实现就行了，从Ops的角度看，高可用、监控、报表这些东西在业务正式上线前就是必须要考虑的。
因此，DevOps实施成功的关键，涉及到团队管理，项目管理，技术管理等诸多方面。DevOps并非治病良药，如果团队正能量大，实施起来就相对容易，否则引入DevOps可能也无法改变什么。对于一个全栈而言，DevOps是一柄必备的双刃剑。
原创：abel_cao
页:
[1]