Devops

devops介绍 https://github.com/lcomplete/TechShare/blob/master/docs/engineering/devops.md全文 定义 DevOps 所要实现的目标都是一致的——缩短软件开发生命周期并使用 持续交付 提供高质量的软件，开发运维之间 沟通合作 发展背景： 敏态需求的增加，即探索性工作的增加： 软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求，近些年创新型的应用不断涌现，这些应用的研发过程中多采用小步快跑、快速试错的方式，这些探索性工作要求运维能够具备一天发布多次的能力，需要企业完成由稳态到敏态的转变 软件开发活动在企业经营活动中占比的不断增加： 业务发展对软件的依赖由轻度依赖、中度依赖发展到目前的重度依赖。 企业存在对消除浪费的需求： 软件开发活动在企业中的位置越来越重要，软件开发活动中也存在着许多的浪费，企业管理上必然存在着 识别并消除浪费 的需求 软件开发中的浪费包括不必要和必要的浪费： 不必要的浪费有：无人使用的功能、软件bug、等待测试、等待审批等 必要的浪费包括：工作项移交、测试、项目管理 以上为深层原因，浅层原因有：容器化技术的发展、微服务架构的发展等等 DevOps原则 DevOps 原则是总体指导思想，实践是具体的执行方法，DevOps 是一个动态的过程，在进行相关实践的时候可以看看其应用了哪些原则，当违背原则的时候需要思考实践的合理性 三大原则： 流动原则：加速 从开发、运维到交付给客户的流程 反馈原则：建设 安全可靠 的工作体系 持续学习与实验原则：采用科学工作方式，将对组织的 改进和创新 作为工作一部分 流转原则： 坚持少做 产品开始开发时采用 MVP 原则（最小可行产品原则） MVP要求抓住最核心的产品流程，剥掉多余的功能或者高级功能，只要主流程可以跑起来可以。完美并不是我们的目标，快速试错才是我们目标 产品迭代时要适时做减法 持续分解问题 大的变更或需求拆解为一系列小的变更，快速解决 工作可视化 采用 Sprint 看板将工作可视化 控制任务数量 减少前置时间，降低测试人员的等待时间 任务越多，预估越不准确 减少交接次数 减少不必要的沟通和等待 持续识别和改善约束点 识别出影响流动的主要前置因素，比如搭建环境、需求文档 QA、开发、运维、产品持续提升生产力 为非功能性需求预留20%的开发时间，减少技术债务 消除价值流中的困境和浪费（导致交付延迟的主要因素） 半成品——未完全完成的工作 额外工序——从不使用的文档、重复编写接口文档等 额外功能——用户实际不需要的功能 任务切换——将人员分配到多个项目或截然不同的工作任务中 等待、移动、缺陷、非标准化的手动操作 返回原则 在复杂系统中安全地工作 管理复杂的工作，识别出设计和操作的问题 群策群力解决问题，从而快速构建新知识 在整个组织中，将区域性的知识应用到全局范围 领导者要持续培养有以上才能的人 及时发现问题 快速、频繁和高质量的信息流——每个工序的操作都会被度量和监控 技术价值流的每个阶段（产品管理、开发、QA、安全、运维），建立快速的反馈和前馈回路（包括自动化构建、集成和测试过程） 全方位的遥测系统 在源头保障质量 过多的检查和审批流程，使得做决策的地方远离执行工作的地方，这导致流程有效性降低，减弱了因果关系之间反馈的强度。 让开发人员也对系统质量负责，快速反馈，加速开发人员的学习。 为内部客户优化工作 运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要 持续学习和实验原则 建立学习型组织和安全文化 将日常工作的改进制度化 把局部发现转化为全局优化 在日常工作中注入弹性模式 缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时解耦架构，都属于在系统中引入类似张力的做法。 领导层强化学习文化 领导者帮助一线工作者在日常工作中发现并解决问题 DevOps实践 基于 DevOps 的相关原则，有与其对应的实践，在应用这些实践之前还需认真设计组织结构，使其有利于实践的开展...