敏捷和精益的升华，敏捷精益升华
敏捷和精益的升华，敏捷精益升华
DevOps，从2009年的提出，到现在相关的各种工具集和服务的涌现，其方法理念、支撑工具以及业界经验都在不断的完善和日趋成熟。那应该如何全面的理解DevOps呢？我们可以根据why-what-how的原则来逐项叙述。
Why - 为什么要关心DevOps，DevOps能解决什么问题
到今天为止，软件系统和软件开发已经发生了很大的变化，并且这种变化还在继续。我们大致可以将目前的软件系统分为两类：传统的记录型系统和新兴的参与型系统。
- 记录型系统，如典型的CRM，ERP或者HR系统都属于记录型系统，这类系统关注于数据和交易的完整性，要求稳定和符合规则，运维成本很高。
- 参与型系统，各种移动应用，比如微信，微博等等都属于参与型系统，用户参与是这类应用系统的核心价值，所以系统注重用户体验的不断提升，要求敏捷，灵活和可扩展。
然而实际上，这两种系统并不独立存在。举个简单的例子，我们经常使用的个人银行系统，前端的手机银行和网络银行都属于参与性系统，而后端则有属于记录型系统的核心银行系统。不同系统之间需要相互集成。当我们接收到一个参与型系统的客户需求时，因为涉及到与记录型系统的集成和交互，软件交付的复杂性大大增加了。例如，在规划，流程和集成上都需要仔细的协调和沟通，要处理好不同团队，工具，流程和平台间的复杂依赖关系，整个交付对于沟通协作和流程透明度的要求也提高了。
那么在这种复杂的场景下，企业如何还能在创新和快速交付方面保持领先呢？这就是DevOps想要解决的问题。
What - DevOps究竟是什么
DevOps发展到今天，已经不再是字面上解释的Development（Dev）+ Operation（Ops），而是一种持续交付的企业级能力，目的是为了使组织或者企业迅速捕获市场机会，缩短客户反馈的时间。
如上图所示，DevOps这种企业级能力其实是一个能力集合，包括整个软件交付过程中所涉及到的持续的商业规划，协作开发，持续测试，持续的部署和发布，持续的监控和持续的客户反馈和优化。所以，在讲DevOps时，我们不光讲的是一个框架，一套理论和一系列工具，我们其实在讲的是一种涉及到业务负责人，开发团队，运维团队以及目标客户之间的协作和互动，是从掌控到开发测试，到部署，再到运维，最后回到掌控的不断持续的改进过程。这和我们前些年做敏捷改进是一样的，要解决的不光是技术和工具的问题，还要在组织、文化以及流程上做一些改变。DevOps正是基于敏捷，并引入了精益思想的又一次变革。
在我所在的实验室，我们从2006年开始敏捷之旅，经过不断的改进和磨合，到2009年，各个开发团队已经能在保证产品或者产品线的快速、高质量的发版大节奏下，灵活安排自己的小节奏，主动高效的完成团队和个人的开发任务。然而敏捷只能提升开发团队的工作质量和效率，随着云和互联网技术的不断发展，这种提升已经不足以满足业务创新的需求了。我们需要做到和某些成功的互联网公司一样，更快更灵活，需要从更广阔的视角来看待软件交付的改进。
精益思想最初起源于80年代的日本丰田的精益生产。这种关注于价值流动，减少任何浪费的管理思想使得日本汽车工业在世界舞台上迅速崛起。借鉴于精益思想，DevOps关注软件交付过程中价值的流动，以透明的流程管理和自动化工具链来减少沟通协作以及开发运维等各交付管道中的浪费。持续的监控和客户反馈使得软件交付中的潜在问题能被及时的捕获和解决，进而转化为新的价值。
How - 如何开始实践DevOps
既然DevOps的实践是一个持续不断的改进过程，那我们就需要有计划有目标地循序渐进。每一个过程可以分为三个步骤：评估，制定计划，辅以工具实施。
- 评估
- 制定计划
- 工具与实施
可参考资料：
精益思想
IBM DevOps自我评定工具
IBM DevOps主页
IBM Bluemix DevOps Service
评论暂时关闭