DevOps时代下工做整合问题前端
什么样的工做须要整合，什么样的工做不该该整合？python
在软件交付领域，分角色的精细分工是不利于总体交付效率的，那为何在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢？如何解决这些新问题呢？ios
也许，咱们须要认真思考，在整个软件交付过程当中，什么样的工做须要整合，什么样的工做不该该整合。程序员
在前DevOps时代，分角色分工的思路实际上是来源于工业时代的。作过手工的都知道，若是要手工作100只灯笼，一开始会作得很慢，作了几只后，会越作越快，所谓熟能生巧。redis
再进一步，把作灯笼的过程拆解一下，好比拆解成搭骨架、糊纸、上色等工序，而后多找几我的来，每人负责其中一道工序，通过几番磨合，因为每一个人要作的事情比较单一，很容易上手和熟练，效率将会大大提高。灯笼的成品和质量也会越来稳定。shell
把这个过程放大，就是一个工厂的模式。数据库
全部工厂都是经过拆解和精细分工得到极高的效率的，并且，分工越精细，效率越高。而生产最大的特色是在不断地作重复的事情，产出是一样的产品，并且产品间的差别越小越好，最好趋近于零。对于重复的事情，就应该经过拆解、精细分工、标准化和自动化来提高效率。api
可是软件交付过程则彻底不同，和生产最大的区别就是“不重样”。ruby
每个软件需求都是不同的，用户想要的结果也是不同的，这致使需求分析、开发、测试面对每一个需求，或者运维面对每一个故障的具体工做是不同的。服务器
并且软件交付是一个知识工做，是信息流动和转换的过程，而交接会带来信息的衰减和变异，所以在软件交付过程当中，按角色分工非但不会带来像生产那样的效率提高，反而会由于信息在不一样角色间的交接和传递而产生没必要要的摩擦和误解，甚至交付出错误的软件产品。
所以，咱们更但愿软件交付团队成员能够具有从需求到运维的端到端的交付能力，每一个团队针对一个特定的业务领域可以独立完成交付，减小交接，减小对外依赖。
并且这个团队应该足够小（最好很少于7人），以确保团队内目标一致、高效沟通和高度灵活。
然而，对于业务或用户来讲，IT系统和服务是一个总体，除了软件，还有硬件。而每一个人的带宽和能力都是有限的，术业有专攻，不可能每一个人都是全能的，特别是有些细分领域专业度很是高。
若是把全部的职责都归到业务线交付团队，那么交付团队必然须要拥有具有各种所需技能的专家，从而造成新的庞大实体，除了形成没必要要的资源浪费外，组织一旦变大，势必又会变得官僚和低效，本来想避免的问题又会从新出现。
3、解决工做整合问题的关键
要找出哪些工做是重复的，哪些是非重复的。
那么问题的症结在哪里呢？经过前面的分析，咱们知道，重复的工做，能够经过拆分、精细分工、标准化和自动化来提高效率，非重复的工做，能够经过减小交接和依赖来提高效率。
要解决如何分、如何合的问题，最关键的就是找出哪些工做是重复的，哪些是非重复的。重复的，解决方案是整合资源、角色分工和自动化；非重复的，解决方案是一体化。
那么在软件交付过程当中，哪些工做是重复性的呢？我想到的有如下这些：
一、网络、硬件等基础设施
这些IT基础设施不会由于不一样的项目和需求有太多的差别，并且专业性强，不太适合一人分饰多角，这些角色整合在一个独立团队中，使他们保持专一，也有利于这些专业领域的技术交流和知识传递。
二、部署
应该尽可能自动化，最低要求也应该标准化，有标准的具体做业流程，谁均可以遵守流程作好。
咱们把应用部署过程整理成含具体操做步骤的标准化手册，这样这项工做团队内谁都能作，把他从部署这项具体工做释放出来，在此基础上，让他把这个过程自动化，从而让他学习流水线和自动化部署的技术，接触技术性工做。
他也能够把故障处理流程整理成操做手册，赋能其余团队成员在合规的环境下承担运维工做，把他本身释放出来；
三、DBA、操做系统等专家团队
应该经过脚本、自助服务等形式赋能交付团队在受控的环境下知足交付须要，减小对他们的依赖。
咱们能够收集各交付团队对于DBA的具体需求，把具备共性的需求提炼出来，作成能够经过DBA权限执行的脚本，既知足交付的需求，又确保了DBA权限不会被滥用；
四、标准流程
全部项目都必需要走的标准流程，如采购等，由专业的团队提供服务的形式来执行，大大下降各项目团队因为须要熟悉繁琐流程的过程所致使的没必要要浪费；
需求分析、开发、测试、业务支援等非重复性工做则应该保持在一个自知足小团队中，为特定的业务领域提供软件交付和维护服务。
4、总结
DevOps的目标是实现持续交付，提高总体的交付效率。要实现这个目标，简单地把开发、应用维护，甚至IT运维整合在一块儿，有点过于粗暴。
咱们仍是应该认真分析哪些具体工做是重复的、可标准化的和哪些是非重复的、不能标准化的来分开处置。重复的，解决方案是整合资源、角色分工、标准化和自动化；非重复的，解决方案是一体化。
说说DevOps“像” 什么：
1. DevOps起源于敏捷方法论，或者咱们说的精益原则，目的是为了产品发布更加快捷、频繁和可靠。
2. IT价值流在DevOps的带动下将快速贯穿开发至生产全过程，虽然字面上咱们只看到一个“Dev”和一个“Ops”，感受像是“一带一路”似的，其实包括了从开发到测试，再到发布生产各个环节，下图被常常用到解释DevOps和已有的研发部门角色之间的关系。（其实还应该包括企业的架构师）
“DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产，将由程序员这个遥远的祖宗所繁衍的全部子孙给联合在一块儿。”
以上是Gene Kim对DevOps的解释，供你们参考。
DevOps Check List
这里简单粗暴的列出一些Check List，你们能够对号入座，但不要过度纠结：
1. 开发团队，测试团队和运维团队之间应该没有障碍。三者皆是DevOps统一流程的一部分。
2. 每一个团队的输出都是通过自验证的，这样才能保证DevOps的闭环顺利运转。分享一个DevOps 闭环图：
3. 开发、测试和发布环境标准化，能够很容易将之扩展并进行部署。
4. 每一个团队之间的通讯线路都很明确，保证沟通效率。
5. 全部的团队成员都有时间去为改善系统进行试验和实践。
6. 每次学习到的经验都应该文档化下来并分享给相关人员。事故处理成为平常工做的一部分，且处理方式是已知的。
运维的 “革命”
运维能够说是DevOps这场“IT运动”中受到影响最大的角色，从传统运维到DevOps，就是一场“革命”。
Google的SRE（Site Reliability Engineer），从前一段时间开始，被人们热捧，有的公司立刻把本身的运维岗位换名为SRE，确实显得B格高了一点点。甚至有人把SRE和DevOps划了等号，这样作真让人以为槽点满满。我认为SRE实际上是运维“革本身命”的产物，客观讲，这样的转型是很高明的，必定是经验积累，加思考，再加探索得出的。
SRE是Google的运维团队从实践中总结出来的一套方法论，将工程研发、平常运维和应急响应等任务较好的结合并落地，当Google的运维团队开始在作SRE的时候，DevOps的概念可能还不为人所知。
因此咱们是否应该首先想到是，如何学习Google的运维团队走出适合本身的转型之路，咱们的运维团队将来是什么？
运维的将来是什么？
—一切皆自动化
“运维的将来是，让研发人员可以借助工具、自动化和流程，而且让他们可以在运维干预极少的状况下部署和运营服务，从而实现自助服务。每一个角色都应该努力使工做实现自动化。”——《运维的将来》
说到自动化，感受又是槽点满满，也许有人和我同样都经历过为了自动化而自动化的尴尬，在大公司里，不乏专门作自动化工具的团队，每一年出一套工具，“紧跟时代潮流”，而后被迫使用这些自动化工具的团队怨声载道；可是有经验的开发、测试或者运维工程师必定能体会到，“自动化”对于DevOps来讲，是刚需。
—工具的合理选择
一样对于DevOps来讲，工具是必要条件，但工具不是充要条件，若是沉迷于各类工具的堆砌，那么可能跑偏，下面是咱们常常会提到的一些工具：
代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
构建工具：Ant、Gradle、maven
自动部署：Capistrano、CodeDeploy
持续集成（CI）：Travis、Jenkins
配置管理：Ansible、Chef、Puppet、SaltStack
容器：Docker、LXC、第三方厂商如AWS
编排：Kubernetes、Core、Apache Mesos
服务注册与发现：Zookeeper、etcd、Consul
脚本语言：python、ruby、shell
日志管理：ELK、Logentries
系统监控：Datadog、Graphite、Ganglia、Nagios
性能监控：AppDynamics、New Relic、Splunk
压力测试：JMeter、Blaze Meter、loader.io
应用服务器：Tomcat、JBoss、IIS
Web服务器：Apache、Nginx
数据库：MySQL、Oracle、PostgreSQL等关系型数据库；mongoDB、redis等NoSQL数据库
项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
面对茫茫“工具海”，传统运维团队在日渐式微，而构建工具的团队日益壮大起来，这些工具包括持续集成环境和持续交付等等。运维能力应该逐渐延伸到构建和维护基础设施服务、配置管理、日志管理、容器管理以及监控等多方面（深觉得然）。个人建议是，不选别人认为对的，只选最适合本身的。
—熟悉业务
在实践中咱们发现，熟悉业务是团队最难实现，颗粒度最难把握的一部分。
传统运维会有很详细的分工，包括团队之间和团队内部。有的团队之间会作隔离，举个小例子，“今天上线的内容，我须要你每一步都写的清清楚楚，我只负责执行，不问为何，出了问题我不负责”，听上去是否耳熟？其实问题不在于要求上线申请写的多清楚，问题是对业务相关“我不负责”。在传统运维团队内部，通常有专门负责部署上线，跑脚本的同事；有DBA，数据库全部操做就是“我”来；有作监控的同事等等。固然各个公司状况或许有所不一样，但若是你曾经试着说服运维团队去靠近业务层，你碰到的问题应该相似，那就是或多或少的抵触。
DevOps中的运维团队须要对业务负责，这点毫无疑问，我想你们都没有必要再“害羞”了。事要知其然，且知其因此然。固然按部就班的过程是有必要的，因此在GeneDock咱们选择了一条本身的运维之路。
GeneDock的运维之路
GeneDock的运维团队开始践行DevOps，努力的方向有两个：一是推动自动化落地；二是在原有的“知其然”基础上，要求团队成员“知其因此然”。
自动化的切入点是持续集成和部署，一步一脚印的向DevOps方向前进。目前主要围绕GitHub和jenkins，构建了线上（公有云）和线下（私有云）混合模式的持续集成和部署框架。以下图所示。
业务层面，运维团队在开发团队的大力帮助下，从上线后故障排查，以及配置管理问题的复盘开始，不断在实际问题中总结，并造成文档。同时也经过优化部署流程帮助整个研发团队提升发布效率。团队间相互促进，造成良性循环。
在不少企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具有DevOps能力的组织中，应用程序发布的风险很低，缘由以下 ：
（1）减小变动范围
与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。因为部署常常进行，所以每次部署不会对生产系统形成巨大影响，应用程序会以平滑的速率逐渐生长。
（我的体会：我以为这是敏捷和DevOps最大的优点，对比以前老的开发模式，周期很慢，适用于硬件和传统嵌入式开发，而如今前端技术和中台技术的发展，造就了必须有快速部署、全栈开发的出现）；
（2）增强发布协调
靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电子数据表、电话会议和企业门户（wiki、sharepoint）等协做工具来确保全部相关人员理解变动的内容并全力合做。
（我的体会：软件交付，须要天天每时每刻进行沟通，因此不能采用一周一沟通的方式）
（3）自动化
强大的部署自动化手段确保部署任务的可重复性、减小部署出错的可能性。
与传统开发方法那种大规模的、不频繁的发布（一般以“季度”或“年”为单位）相比，敏捷方法大大提高了发布频率（一般以“天”或“周”为单位）。
（这点，只有大公司有这个能力，我以前的公司维持了一个庞大的团队，专门用于自动化测试，运维…减小后期不少bug和开发时间 ；然而成本也是巨大的，可是比起出bug花费的资源和隐造成本，总之是很值得的）