DevOps基础
DevOps起源
2001年在北美开启敏捷开发大会（敏捷宣言），讨论哪一种轻量级的方法值得被推崇 —— 没最终完美的办法
2008年敏捷大会上
2009年运维大会Flicker大会，指出开发和运维的协作，实现一天10次部署
2009年Patrick —— DevOps之父，决定自己组织一个大会（开发和运维），DevOpsDays大会
\
DevOps 和敏捷开发是一脉相承的，只是把开发和运维如何能实现紧密的协作，它既不是工具，也不是标准。只是一种社区文化
敏捷宣言
敏捷宣言中，两边都是很重要的，只是左项的会更有价值，但不能说右项是无用的
- 个体和互动 —— 重要的是人（对运维来说是有标准化的，但对开发来说不是）
- 工作的软件 —— 过度复杂的文档化对用户是无价值的，对用户来说有用的是最终的项目
- 客户合作 —— 合同双方的目标和利益是不一样的，不能仅仅依赖于合同谈判（合同也许没用，但出现分歧的时候就很有用了）对devops来说 客户和研发之间需要有更多的信任
- 响应变化 —— 仅仅依照计划是不足够的，开发要基于变化的响应
运维来说——流程和工具 运维是工单驱动的 但在如今的互联网环境下这是不完善的，
- —— 文档 是必须的
- —— 合同 SLA 也是必须的，但这数字化的背景下，仅仅基于合同办事是不足够的，大家运维，开发，都是同一个目标
- —— 计划 提前告知运维计划是很重要的
敏捷倡导的理念
精益思想
- 价值 —— 要有产出的服务和产品背后是有客户的 不同的职能的人在一起
- 价值流 —— 如何把价值给到客户手里（如何让价值流能更顺畅得流动）
- 流动Flow —— 做的事情让价值流流的不受阻碍 前3点做好就是很好得价值流体系
- 拉动 —— 确保价值流上得东西是真正有用的 也就是客户需要得 知道具体需求，在执行具体工作
- 尽善尽美 —— build in quality内建价值， 价值流中的每一件事都要做好，避免返工 ，前面得每一条做的时候都要有及时得质量反馈 5点，极致的工程效率
精益的浪费
- 库存 —— 过时得需求没完成就是浪费得
- 过度处理 —— 文档的过度处理
- 过度生产 —— 做出来得东西客户是不需要得
- 运输 —— 多任务得切换，任务之间得移交，需求分析移交给研发，研发给测试
- 等待 —— 100个需求同时启动，按照瀑布流程来说，第一个需求做完了就需要第100个做好的才能移交到下一步
- 移动 —— 没断言单元测试就是无意义得移动
- 缺陷 —— 造成返工
- 没有被充分利用得人的才能 —— 发挥每个员工得主动创造力 主观能动性
基础设施即代码
把基础架构当成代码来管理，这对运维来说是非常大得变革，在这件事情做到之后，就不能像以前一样直接ssh过去部署或修改，就需要改代码然后重新跑一遍流水线
Devops可以调用API（docker等）来管理环境，按需来生成环境
云设施 —— 非常重要，上docker，上云
云上面得管理单位是容器，就把一切没解耦得东西搬到docker上，和以前部署到服务器上没根本上得区别
云上得docker 需要实现清晰得接口边界
- 按需得自我服务
- 宽泛得网络服务
- 资源的池化
- 快速的可伸缩性
- 服务可度量 —— 按需使用资源
以上发挥得越多，云服务实现得越好
