devops 随想
#devops 随想 #
早上听了一个 #devops 历史介绍的文章，很有意思。
TLDR： 最早devops 提出的人是一个叫帕特里克 · 德博伊斯（Patrick Debois）的 IT 咨询师。他在一个数据迁移项目中遇到了实际的开发（dev）和运维（ops）的冲突问题，这类dev和ops之间的冲突，在一些比较传统的软件公司中每天都在发生。 帕特里克遇到的具体问题有可能跟我遇到过的换电站发布运维的问题极为类似，
- 开发人员，希望通过更多的迭代来优化自己的程序
- 运维人员，希望减少发布次数来换取系统的相对稳定 这是一个本质上的矛盾与对立，如果没有更好g的技术支持，这类矛盾则难以化解。
2009年，Flickr公司运维部门经理约翰 · 阿斯帕尔瓦（John Allspaw）和工程师保罗 · 哈蒙德在 Velocity 大会上做了一个轰动世界的演讲：《每天部署 10 次以上：Flickr 公司的 Dev 与 Ops 的合作》（10+ Deploys Per Day: Dev and Ops Cooperation at Flickr）
这次的演讲，提出了一个观点：dev和ops的矛盾可以通过技术升级和文化构建来解决。devops就此诞生。帕特里克也从中获取灵感，同年筹备了自己的Velocity大会，他把大会命名为devops days。
大会出乎意料的成功，devops一词在twitter上广泛流传下来。
cloudbase 服务ops 难点 #
当我们希望一个dev 开始操作ops 的时候，我们会发现，他无法立刻胜任。
在他不熟悉到熟悉的过程中，常常会因为不小心或者种种无意的原因导致环境调试成本增加。
ops不止是一个简单的技术栈，而是包含了monitor，deploy，工具，性能分析全面的事情，并不像编程语言一样垂直。
dev是一个一天八小时的事情，但是ops是一天24小时的事情，要做到精进，需要持续投入。
不同公司对于ops 的定义要求差别甚大，对云端服务托管以来较重的公司不需要掌握过多的基础设施技能，但是自行维护各种中间件的公司则需要许多下沉的技术。
物联网ops 难点 #
硬件公司常常只了解传统软件工具，ops仍然是以现场部署的方式为主。
物联网设备分布广泛，难以集中管理
物联网设备量大
存量版本众多，需要大量向回兼容工作
升级动作相对被动，出于对安全的考虑，需要较多的终端操作。
依赖硬件版本和硬件框架设计
那么众多难点下我们怎样才能每天部署 10 次以上呢？before how，我们还是先讨论一下why。
为什么我们要”每天部署 10 次以上”？ #
https://agilemanifesto.org/iso/zhchs/principles.html 这个只有几个字的静态页面的网站里提到：
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
个人观点，在发布到产品之前的一秒钟，团队的价值都没有任何体现，对于软件开发，或者其它行业来说，只有交付之后，才开始及早的给产品代理实在的价值。
尽早的交付能够带来更多的价值，因为时间同样是成本：
- 交付一个bug的修复，能够减少bug出现的次数和减少bug带来的负面影响
- 交付一个新功能，能够给产品提供更多的线上验证时间，能够更快的作出下一步决策 当然这一切的前提都是上线一个经过思考的稳定测试过的版本。
How？-> Answer: 技术升级 #
09年提出一天发布10次的人，肯定还没有容器化技术，肯定没有跟如今一样好用的云服务技术，我不知道他们提出这样想法的底气是什么。
但是今天我们每个人都应该能够很自信的告诉自己，如何feature 一旦完成开发周期，他就应该出现在线上，为我们的产品争取时间。这样一说很简单，但是背后需要的技术支持是全链条的支持。
从开发->测试->部署每个环节都需要紧锣密鼓的
- 每个因为流程而暂停前进的需求，都应该需要被反思。
- 每个因为人工操作而产生的延误都需要被自动化
- 每次的down机都需要有自动重启的机制
- 每次的编译失败，线上bug都需要考虑是否应该在更早一步的时候发现
最后形成一套稳定的体系，持续运作下去。每节约的一分钟都是n次发布的1*n分钟。
How? -> Answer: 文化构建 #
追求精进 #
是每个敏捷团队的基本素质，如果有人认为团队的流程将将就行，他做的ticket 也是将将就行，他交付的质量也是将将就行。
将将就行的思想会像癌症一样蔓延到每个成员身上，最后一蹶不振止步不前。
尽早交付 #
尽早交付是能够帮助团队体现价值的。
开放包容 #
并且需要一个开放包容的环境，对工具使用的开放，对新鲜事务尝试的开放。
当然还有许多关于沟通合作，以简洁为本，等等等的文化，若是一个企业没有这些文化作为支持，很难孕育出一个牛逼的团队。相反，可能会孕育出一个作风官僚，流程繁琐，效率底下的团队。