上两周在上海出差，工作比较忙，没有及时更新文章，对自己提出批评。之前看到Dr.Fish写的《2017- 我的敏捷学习之年》将scrum用于自己的学习，深深的佩服鱼心博士的自制力，感慨学霸的帽子不是白扣的。受此启发，或许自己可以写一些关于devops的心得，自己不是资深Devops专家，仅仅了解些Devops的思想，全当总结。
Devops
image.png
关于Devops，从字面意思上说就是开发运维一体化，而带来的组织变化如下图所示。
组织结构变化.png
在我看来，关于IT工作可以分为四类：业务项目、内部项目、变更以及计划外活动。无论devops或者scrum都是站在更高的维度来看IT运维以及开发那点事。二者并不是什么新技术，都只是在传统制造业管理理论中衍生出的优化IT工作流的管理方式而已。旨在统筹全局(开发、测试、运维)确保计划内工作流的吞吐量最大，从而向业务部门交付工作价值，同时尽可能的降低计划外工作的影响，减少返工。
提到Devops, 不得不提三步工作法：
- 工作从开发部门移向运维部门再到客户时，如何建立快速工作流，因为开发、测试、运维部门是业务部门与客户之间的衔接。必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起顺利变更的安全系统和组织。
- 如何缩短并放大业务部门与客户之间，开发与运维之间的反馈回路，避免返工（浪费）
- 如何建立一种工作文化，既能鼓励探索，从失败中吸取教训，又能让大家理解反复实践是精通的先决条件。
Devops是把双刃剑.jpg
而实际工作中Devops是把双刃剑。其实风险本身并不可怕，可怕的是拒绝风险，或者放任风险。大家可能已经看过很多DevOps宣传，觉得实行DevOps之后可以做到万无一失，从开发到交付是分分钟搞定的事情。其实这里有个陷阱。那就是工具可以帮助生产到交付快速进行，但是从另一个角度讲，如果一旦出现问题，错误也可能会很快传递到生产环境中。所以如何快速捕捉问题，解决问题，而不是让问题传递，这才是DevOps要处理的问题。另外尽早的在持续交付的初期发现问题，比如说有价值的缺陷，然后把它作为单元测试的目标去防范，这对于团队来说是一个不断成长的过程。
“精益的侧面是控制风险，所以要小心风险和DevOps流程一起传递。”
怎么实现一个scrum
Scrum也有自己的四步法：
- Sprint(冲刺)计划。 列举总的任务清单并进行估算，根据优先级与难易程度，明确近期Sprint中需要完成的任务。
- Sprint执行。 按照将要执行的Sprint计划，完成Sprint。每日以站会的形式，在15mins左右的时间回答：昨天做了什么，今天要做什么，遇到了什么困难。
- Sprint评审。评审在每个sprint结束时召开，由开发团队展示sprint完成的功能，不需要PPT，一般展示已完成的demo，需要由客户、经理、开发人员、product owner参加。
- Sprint回顾。由scrum团队、产品责任人等进行复盘，回顾经验并吸取教训，宗旨是scrum团队如何在下一个sprint中做的更好。
Devops和Scrum的关系
image.png
很多人好奇敏捷和DevOps是什么关系。敏捷是一种软件开发过程，最初只是在软件开发中推广，很多人提出由开发敏捷转型到运维敏捷，从而到业务敏捷。这个提议毋庸置疑，不管从文化，流程以及工具层面都是很好的延伸。可以说敏捷方法，敏捷工具为DevOps理念提供了很好的理论指导和工具支持。近些年来很多公司逐渐开始进行敏捷实践，比如说项目经理变成了Scrum主管，用户故事替代了以前的需求，开发计划变成了更短的冲刺计划。以前每周一次的组会变成了每天的站会。一开始大家都精神满满，久而久之觉得每天的站会太麻烦。而Scrum主管还是以前那个逼着大家干活儿的项目经理。冲刺使得开发周期变短了，能做的功能也变少了。频繁上线给运维人员带来更大的压力，生产环境的Bug似乎比以前还要多。
“如果不了解团队自治，责任共担，面向交付，那就不了解DevOps文化。”
Devops实践
自治型的小型化团队
自治型组织.jpg
这点对于很多公司，特别是目前国内的诸多公司来讲也许很难做到。组织的自治意味着控制力的减弱。控制力的减弱加上人类天生的惰性将导致项目的失败。这可能是团队转型中存在的共同问题。实际上自治并不是说缺乏管理，而是说对目标做出正确的期望，对结果做出合理评价。中间的过程通过一系列的检查点做出指导和纠正。其余的工作交给团队去协调完成。
Image_20170601100812.jpg
首先敏捷实践中将用户故事，任务等明确责任人，这是非常好的做法。明确了责任，大家才能向目标迈进。而另一个责任共担的好办法是让每个人参与团队计划的制定，大家帮助任务的负责人共同估算出故事点。这样不仅会培养团队成员的责任感，并且最终估算的结果会比项目经理自己做出的决策更加准确。在项目执行的时候，看板等工具的运用使团队中每个参与者的工作都具有相同的可见性。以看板中待办项以及任务状态确定每天站会的内容。而不是架构师汇报技术难点，项目经理汇报开发状态，大多数人被忽略的情况。
Image_20170601101332.jpg
不超过10人的小团队被很多企业证明是一个良好的实践。可以让对的人去做擅长的事，如果团队过大很多人无法承担合适自己的角色也是一种浪费。另外随着持续交付的演进，产品总有新的需求，也有旧的问题。如何合理分配人员从而做到一石二鸟？一些组织开始将团队分为若干个特性团队和维护团队。这样能带来以下好处：
- 每个特性团队都有一个架构师，同时也是Scrum主管。由于人数小所以很容易做到工作进度与工作量的管理。
- 特性团队和维护团队，互相轮岗。在维护团队中，成员可以接触客户，新成员可以通过修复Bug熟悉产品，对产品足够成熟后再轮岗到特性团队。
- 不同的小团队甚至可以不用在一个地方。
- 从DevOps的角度，一个大的产品团队就可以完成项目开发到上线的整个交付工作。
全程可控的追溯工具
核心的概念其实就是让我们在工具上所做的事情在不同的生命周期时可以做到全链路的可追溯，因此我们给出以下实践：
- 从需求出发，驱动任务执行。
- 任务和代码生产相结合，进行追溯。
- 以任务为单位进行持续集成。
- 以需求为单位进行持续交付。
- 以质量为纲，进行系统验收。
- 运维规范化。
- 随时随地的沟通。
- 持续监控，持续改进。
基于以上的思维，越来越多的公司都会在原有开源工具之上，构建devops环境。 核心工具如下（网上的图片和我自己用的不一样）：
image.png
这种集成方式给运维带来的改变可能要多于传统的研发，因为传统的运维在方法论，工具，规范程度等方面还远不及开发，比如说：
- 与很多成熟的开发流程脱节，以及生产环境的相对隔离造成了运维的黑账本（碎片化的脚本）。
- 环境部署后，使用者和管理者的信息不同步造成了很多僵尸系统。
实时的度量驱动
软件开发过程中充满了各种各样不确定的因素，有时一个小情况的出现就会成大程度影响软件产品的按时交付。对于中高层管理者来讲，只能通过重复的人工周报月报来获取信息。然而不及时，且掺杂人工数据的报告讲给决策支持带来很大的误导。DevOps就是要将数据链路打通，为管理者提供实时，准确的生命周期数据。使管理者在风险到来之前有效的对其管控。
image.png
可能在传统的印象中度量不就是一堆报表吗？其实这里有个很大的误区，那就是度量的方法更多的是通过数据看趋势，事先为管理决策作出支持，而不是事后分析。比如说项目经理在看到缺陷不断呈现上升趋势就应该去寻找问题，进行干预。Scrum主管在看到任务周转时间要长于原先的预估时间，那就要评估原先的冲刺计划是否能达成。实施度量正是切合敏捷的拥抱变化的理念，帮助项目的参与者尽早的发现问题，在需要的时刻做出干预。
将以上三者结合起来
image.png
用什么方法能将三者融合起来呢？我们发现使用Kanban（看板）Baseline(基线)和Pipeline(管道)这三种方法可以将任务管理，版本控制，过程管理紧密的联系在一起。
看板：以任务的状态为核心，管理在制品的生产情况。任务是自组织团队的工作契约。
基线：以工件的版本为核心，选取合格的交付物。比如说开发团队决定哪个代码提交版本，或者编译的构建版本为最终交付的版本。度量指导基线的产生。
管道：以生命周期阶段为核心，控制基线交付物的投产。比如说一个合格的代码基线目前处于编译态，还是部署态。自动化工具围绕管道互相集成。
image.png
那什么又是将这三者融合在一起的方法呢？答案就是工作项（WorkItem）。它涵盖了需求（长篇故事，特性，用户故事），开发（任务，缺陷）,测试（测试用例，测试计划）等。
工作项是看板展示的最小单元，看板的泳道就是工作项的状态。
基线是通过需求工作项规划，任务工作项生产，测试工作项验收的最终产物。
工作项是生命周期不同交付物的容器，交付物的最终投产通过管道体现。
image.png
最近这几年可以说IT行业发生了一个质的改变。不论从方法论，还是软件工具以及基础设施都让软件开发这件事与业务结合的越来越紧密。可以说DevOps就是云平台开发运营的指导思想。在人员角色方面，推崇全栈工程师，让开发者更贴近业务。在开发方法方面，而在这个平台之上从开发到运营流转的交付物就是以微服务方法开发的应用。在物理形态方面，以容器的方式交付到生产部门运营。对于使用者来讲，这种业务的最终交付形态可能就是一系列的API接口，或者直接可用的应用。一切都变得平滑起来。
基于以上内容，我将如下的内容应用到日常的工作当中（目前想到的不分先后）：
- 重新定义完成的含义。之前开发部认为代码开发完就算完成，并没有给测试以及运维部预留时间，而今被认可的完成是开发、测试、运维整套流程走完并被认可才叫完成。
- 重新定义了变更的定义。之前肤浅的认为做重大配置改变时才叫变更，比如修改数据库的配置文件。现在所谓的变更即对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或者虚拟操作、以及其他可能对相关的服务产生影响的操作都叫变更，只不过严重等级不同。看似简单，但是对于日常运维等，思维的改变很重要，会改变许多流程的定义。
- 将变更的流程通过日常训练，让工程师形成了一种习惯。高危险变更必须提交申请并量化，必须杜绝未经授权的高危险变更。
- 建立了可视化的工作管理工具，并在整个系统中应用起来。比如看板：在办、待办、已办。比如重大变更：变更内容、开始时间等。
- 应该重视员工的加班状况。员工加班除了自身原因之外，应该思考是否是任务分配的时候出现了问题，是否是计划外任务导致的。有个理论，等待时间=忙碌百分比/空闲百分比，比如忙碌时间占到了日常工作的90%，空闲时间占到了10%，则等待时间就是9个单位时间。而日常的运维工作普遍存在计划外任务的情况，所以尽力减少排队等待的时间。
- 识别项目或者流程中的约束点并且加以保护，比如设立三级工程师。对于约束点外的改进都是徒劳的，换言之，不要让约束点浪费任何时间，不要让约束点为了前就别的资源而处于等待的状态，应该专注于工作中优先级最高的那一项。
- 应该想尽办法消除计划外工作，它直接影响了开展计划内工作的能力。
- 应尽量为工程师剔除无用的工作。在外企中很多强制但无用的工作直接影响了员工的时间，应对其加以控制。
- 注重例会、周报、月报的状态更新。
- 适当的让团队成员展现缺陷或者脆弱面。
- 应该整体把控项目是朝着正确的方向发展，这点scrum做的很好，模块化的工作，船小好调头。对于IT部门，目标是提高整体的系统生产力而不是提高任务完成的数量。
- 管理好工作交接。
- 规范了第一封邮件回复格式。对于技术支持团队，要求其中含有计划完成时间这个强制选项。
- 在部署管道中构建和测试失败时，采取安灯拉绳的方式，停止整条流水线的作业。看似浪费时间，实则返工造成的消耗更大。
- 必须跳出IT领域，识别由于IT引起的业务风险才能看清IT部门的任务和绩效问题。比如何业务部门沟通，明确公司的愿景->细化到公司的绩效->细化到业务依赖IT的方面->细化到由于IT可能会导致的业务风险等，由上而下的细化，由下而上的保证。
- 持续对IT系统实施监控并设立预警值。
- 保证开发、QA和生产环境相一致。在弄清楚所有环境保持同步之前，暂停部署。Docker和openstack很好的帮助了这一点。
- 跟上客户需求。社会越来越多的产品是快速上线、快速消费、快速淘汰。
- 建立可同时创建开发、QA、生产环境的构建规则以及自动化机制。
-尽量让业务部门和IT部门作出同向的决定。 - 开发团队不再是孤立的点而要将20%的时间用于帮助确保工作顺利通过下游部门（比如QA，运维部），加快自动化测试，改进部署基础架构。
- 在保证功能性要求的前提下，重视非功能性要求（比如可扩展性、质量操作性、安全性等）
- 建立同事评议制度确保每个人对代码和运维工作有信心。
- 通过第二条使开发人员在工作中不断的获得迅速反馈：在代码编写时，自动单元、验收和集成测试一直在类生产环境中，使环境也一直处于可部署的状态。
- 对于新功能，开发部可以很早就发布但通过配置的方式对用户不可见，在内部测试，之后以极小的，可控的状态逐步开放。
最后我想说的是，IT像是毛细血管深入到公司的各个角落，我认为一个好的IT团队不代表他们拥有最聪明的人，使团队变好的因素是每个人都相互信任，同时挑战也在于如何让员工同心协力想着同一目标迈进。于我，尽管我所在公司以及大部门的离职率很高，但我自己的团队在过去的两年中至今没有一个成员离职，这是对我个人最大的肯定。在带领团队的过程中，我一直遵循以下两点：
- 我一直在工作中试着做到公平，即使没有做到完全的公平也会让团队成员知道我是在尽力在做到这一点。
- 尽力为员工争取福利，毕竟我们都是打工仔。马老板不是说过离职就两个原因一是不开心二是钱没给够。我真是在自己的职责范围内，尽量为大家争取福利。
另外，我也将scrum思想应用到了个人任务的日常管理中，用了teambition的看板工具将个人家庭任务列成backlog，每日更新状态。teambition手机和电脑同步，免费版已经够用。
最后，
感谢DrFish给予的写作灵感；
感谢过去很多年中和自己并肩作战的小伙伴们。
感谢压寨夫人每日辛苦的带小核桃给予我最宝贵的时间。
下面是devops工具的一些摘抄, 仅供自己后续学习时参考
版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
自动化构建和测试:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
持续集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
容器平台: Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
服务开通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
日志管理：Logstash、CollectD、StatsD
监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
网友评论