#onenote# devops

Measuring Your DevOps Success

http://www.datical.com/blog/9-metrics-devops-teams-tracking/

https://dzone.com/articles/measuring-your-devops-success

DevOps Metrics for Baselining and Measuring Success

There are hard, quantifiable technical and financial metrics we can track, such as:

      • Number and frequency of software releases
      • Volume of defects
      • Time/cost per release
      • MTTR*
      • Number and frequency of outages / performance issues
      • Revenue/profit impact of outages / performance issues
      • Number and cost of resources

Cultural Metrics

      • Cross-skilling, knowledge sharing and pairing between teams
      • Working in a fluid but focussed manner
      • Working in multidisciplinary teams
      • Organizing teams around projects rather than skill-sets
      • Constantly dancing on the edge of failure (in a good way)
      • Position around business demand
      • Extraneous lines of code
      • Attitude to continuous improvement
      • Obsession with metrics
      • Technological experimentation
      • Team autonomy

You can also look at a number of team features such as:

      • Rewards and feelings of success
      • Hierarchical and political obstacles and annoyances
      • Inspiring and fostering creativity

Process Metrics

      • Requirements elicitation and management
      • Agile development
      • Build
      • Release and deployment
      • Unit testing
      • User Acceptance Testing
      • Quality Assurance
      • Application Performance Monitoring
      • Cloud

”如果DevOps不是一个角色,一个资格,一个头衔 ,那么它到底是什么呢?Kavis的定义是:

DevOps是一种文化转变,或者说是一个鼓励更好地交流和协作(即团队合作)以便于更快地构建可靠性更高、质量更好的软件的运动。

DevOps是软件开发生命周期(SDLC)从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷,它的关注点是从SDLC中移除浪费。通常情况下,发现浪费或者瓶颈的形式包括:不一致的环境,人工的构建和部署流程,差的质量和测试实践,IT部门之间缺少沟通和理解,频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。

我看到的另一个重复模式是:一个“DevOps”团队的第一步通常是决定他们是否应该使用Chef或者Puppet(或者是SaltAnsible等其他任何热门的东西)。他们甚至还没有定义自己打算解决的问题,即使他们手头的工具可以解决它们。这些团队通常会紧张地构建数千行脚本,但是这就产生了一个问题:“我们的职责是编写Chef脚本还是通过质量更好、更稳定的产品更快地进入市场?”。在大多数情况下,这些团队会将自己逼入绝境,大量的专有脚本实际上是增加了系统的浪费,而隐藏在DevOps运动之后的驱动力是从系统中移除浪费,这些团队并没有做到这一点。

为了完成这种合作,组织内部必须要有人描绘一个DevOps愿景。这并不能通过教学过程实现,因为人们只会尝试着机械性地遵循这些步骤。我们需要的是教会大家一种思维方式。根据Edwards所说,这可以通过遵循下面的几个步骤实现:

      1. 教导基本的概念,例如“单件流、批量工作、限制在制品的数量、拉式vs推式、持续交付”以及可以使用的工具等组织将会共享的一些通用词汇的概念。
      2. 让所有人目标一致,通过:
        a. 价值流程图——一个精益概念,它详细描述了一个组织内部发生的信息流和制品流,引导价值创造。
        b. 时间线分析——试图发现时间花费在哪里,瓶颈在哪里。
        c. 浪费分析——确定一个组织所产生的各种各样的浪费以便于尽可能地消除浪费。
      3. 发展度量链,它的意思是对价值交付链中的各个活动进行度量,发现各个活动相互之间的影响。
      4. 针对基线识别项目实验。识别哪些项目或者活动偏离了基线,并且采取纠正措施。
      5. 重复第24步。这一步构成了持续改进流程。

为了实现这些想法,Edwards建议了一个3天的计划:

      • 1天—— 教导原则,提出一个方案进行研究,模式和反模式
      • 2天——分析组织当前的状态,提供问题识别技术和改进指标
      • 3天——讨论解决方案和工具链自动化原则,构建一个路线图

3.持续改进循环

这些循环的目的是通过制定计划、实现计划、测量输出和决定如何持续地改进流程。

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s