节选自百度等资料
知乎解析连接
一、DevOps的目的
只有一个：
提高开发到运维发布版本的效率。
1.初级应用：
开发运维一体化
2.
最高阶的应用
：端到端的概念。
DevOps 的三大支柱之中，即人（People）、流程（Process）和平台（Platform）。即
DevOps = 人 + 流程 + 平台
人 + 流程 = 文化
流程 + 平台 = 工具
平台 + 人 = 赋能
二、DevOps概述
|
|
DevOps
|
|
产生原因
|
由于
软件
行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
|
|
定义
|
DevOps（Development和Operations的组合词）是一组
过程、方法与系统
的统称。
另一种理解：DevOps是
一套实践方法
，在保证高质量的前提下
缩短系统变更从提交到部署至生产环境的时间
。
|
|
作用
|
用于促进开发（
应用程序
/软件工程）、技术运营和质量保障（QA）部门之间的
沟通、协作与整合
。
|
|
如何理解DevOps
|
看作开发（
软件工程
）、技术运营和质量保障（QA）三者的交集。
它是一种
重视“
软件开发人员（Dev）
”和“
IT运维技术人员（Ops）
”之间沟通合作的文化、运动或惯例
。透过
自动化
“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
|
|
产品交付现状和DevOps
|
|
产品交付现状
|
开发和系统管理划分成不同的部门，部门间由于职能存在些许矛盾（特指交付产品过程中存在的沟通衔接等）。
|
开发
|
开发是由功能性需求（通常与业务需求直接相关）驱动的。
交付代码之前，并不邀请运营人员参与架构决策或
代码评审
。
可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。
|
|
运营或运维
|
由非功能性需求（例如可获得性、可靠性、性能等）驱动的。
希望尽量避免修改功能，从而降低满足
非功能性需求
的风险。
可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。
|
|
|
DevOps方式产品诉求
|
|
要做的事
|
1、更小、更频繁的变更──意味着更少的风险
2、让开发人员更多地控制生产环境
3、更多地以应用程序为中心来理解基础设施
4、定义简洁明了的流程
5、
尽可能地自动化
6、促成开发与运营的协作
|
|
成功依赖条件
|
|
领导层
|
勇气和无私奉献，需要花费时间和金钱，并且需要在团队成员筛选上做出艰难的决定。
|
|
调整考核和激励机制
|
应该奖励系统创建和运维的整体团队，并且根据团队工作的全部要素来确定奖励。
而非只根据敲出代码的生产力来奖励开发人员，或者根据基础设施的可靠性来奖励运维人员。
|
|
团队
|
待在一起，共同为他们的应用和系统负责。
应该有开发人员创建代码，从用户界面到业务逻辑和数据结构，也应该有
运维人员负责操作自动化和部署
。
|
|
齐全工具箱
|
依靠各种 DevOps 工具。
例如，开发人员编写代码需要工具、QA测试人员需要用工具完成新版软件的部署，环境准备、将新代码在测试系统和生产系统之间迁移也必须用到云资源调度工具。
|
|
|
|
|
DevOps视角更全理解
|
|
自动化
|
工具可以执行从构建、测试到执行的整个过程，针对生产环境或者一些外部规格说明检查操作的有效性，把过程中发生的错误通知适当的人，并且保留操作历史，以用于质量控制、报告和审计等目的。
脚本和文件也应该进行版本控制，也应该进行错误检查，这个术语通常称为“基础设施即代码”。
|
|
开发团队的职责
|
在DevOps中，开发团队交付、支持并维护服务，这样因为所有所需的知识都保留在开发团队，需要向运维团队和支持人员转交的知识也就少了，就省掉了大量的协作步骤。
|
|
协作优势
|
1、DevOps的一个目标是
最大程度减少协作
，以
缩短推向市场的时间
。
理想的协作机制的特点：从是否有延迟、需要做的准备工作以及人们的时间这几个方面讲，是低成本的，从所有相关干系人的可视性、快速解决问题、有效交流所需信息这几个反面，是高收益的。
2、团队协作：自动化图案对协作机制的目的是保护图案对成员不受自身或其他活动的干扰。
3、跨团队协作：跨团队协作是一个最耗时的因素，DevOps过程试图
尽量减少这种协作
。
|
|
DevOps团队结构
|
|
规模
|
“两个披萨原则”：团队规模应该时两个披萨就够吃的。
|
|
团队角色
|
|
团队领导
|
负责协调团队，获取资源、保护团队不受问题的干扰。这个角色包含了
项目管理的软技巧
，但
不包含注入制定计划、安排日程这样的技术能力
。这些活动最好留给团队作为一个整体去完成。
|
|
退队成员
|
负责系统创建和交付，包括建模、编程、测试和发布等其他活动。
|
|
服务所有者
|
负责外部协作。服务所有者参与系统范围的需求活动，安排团队工作内容优先级，想团队提供来自团队服务的客户信息和提供给团队的关于服务的信息。服务所有者需要既能与其他干系人交流，又能与团队的其他成员交流。
|
|
可靠性工程师
|
多个职责：
在部署完成后立即对服务进行监控，包括金丝雀测试集的使用和取自服务的各种不同的指标；
服务执行期间出现问题后的联系人；
必须深入理解服务的内部，这样才能修复故障或者采用临时解决方案。
|
|
看门人
|
在部署流水线中，决定将服务进入下一步的手动角色。参加决定发布包包含或不包含哪些内容的仲裁会议，了解罚不中包含的所有工作的背景和环境，对缺陷严重程度定级过程中存在的争议进行仲裁，可以批准最新添加的内容，可以坐出取消的决定。
|
|
DevOps工程师
|
负责DevOps工具链中使用的各种工具的护理和保养。这个角色可以是个人、团队或组织层面。
|
|
|
|
三、DevOps岗位职责（招聘节选）
devops工作职责
|
1. 负责线上服务运维与监控、应急响应、故障处理，支撑业务运维需求，保障业务的稳定运行
2. 负责线上服务的架构和质量优化，实现高稳定、高可用的同时，达到最佳访问体验
3. 负责公司自动化运维相关平台的设计和开发，参与公司整体运维体系的构建
|
企业对devops要求
|
|
要求A
|
1. 设计和实施构建运维自动化系统、提高运维、开发协作效率，规范操作流程。
2. 对性能，安全，故障监控有清晰的理解，并在自动化平台中集成相应的报警监控及日志收集功能。
3. 处理内外部用户在平台使用过程中的问题、收集各种反馈意见，对平台进行持续优化；
要求B
|
|
要求B
|
1. Docker、Kubernetes、Mesos等；
2. 熟悉DevOps相关工具
|
|
