如何利用戴明14原则改进质量

质量管理这个话题非常符合企业主和管理者的心意,无论我们从事什么行业,我们都希望做好 - 如果我们能变得更好,击败所有的竞争,那就最好不过了。 爱华德·戴明博士,一个受人尊敬的学者,工程师,商业咨询师,作家,也认为质量是成功的关键。他提出了如今我们熟知的“戴明14要点”。

戴明关于全面质量管理(TQM)的14要点 戴明被认为是对日本二战后经济崛起有重要影响的人,也因全面质量管理中的戴明奖被人们记得。 那么,什么是14要点呢?我们来逐一的看下。

1.对产品和服务改进有“恒定的目的”

戴明相信,为了在市场中保持竞争力,需要设定一个恒定的质量目标,它不是一个短期的承诺,而是一个长期的理念,能保证商业的生存。 当考虑戴明14要点时,很重要的一点就是记得这是关于长期交付的质量规划。

应对式的,短期的解决方案只有短期效果。戴明认为,还需要更具远见的方法。 把同一件事情做的更好虽然不错,但戴明相信商业也应该有创新,研究和持续的产品完善设计。

最重要的一点,他提醒商业活动的结果是为了客户的利益。因此,在做商业决策时,客户的需要应放在第一位。毕竟,没有客户,商业就无法生存。

因为客户需求随着时间在变,这要求商业要做好新挑战的准备,无论我们做什么,持续改进的目标永远要放在心里。

2.采用新理念

产品质量不是嘴上说说的。“恒久的目标”必须通过引入质量的方式来支持。这需要比传统的管理做得更多。 它需要领导力。意味着员工应该自主的去支持质量改进,而不是被迫着去做。

换句话说,戴明的14要点支持创建一种人人都对质量有承诺的文化。戴明在1982年就预测商业运作将从传统管理方式转变为聚焦领导力的管理。如今,他的预言正在商业社会中渐渐成形。

正如企业有愿景一样,我们对交付物的质量也要有愿景。 有了愿景,我们就可以做战略规划来实现它。由于竞争压力做出的应对式改变并不会达成客户第一的目标。 戴明鼓励我们在实现客户需求过程中,把质量管理作为战略优先。

戴明建议了一些方法,包括适当的员工培训,全方位的管理支持,适当的监督以及持续性管理规划

3.质量内建 - 不能依赖检查

戴明不提倡事后质量控制。 他鼓励商业主停止采用靠检查来获取质量的方法。他指出检查会导致缺陷遗漏,而且成本很高。检查除了发现了产品质量的粗陋外,对改善质量并没有帮助。

戴明提倡在商业活动的每个环节中构建质量。 仅仅发现潜在的缺陷还不够,还要追踪并找到问题根源,改善出问题的流程。这样类似的缺陷不会再次发生。

戴明在流程控制中坚持使用统计学方法,这让不喜欢数学的人有点抗拒,但是数字不会骗人。 如果你不喜欢学习如何生成有效的统计,不用担心。 聪明的软件可以帮你做这些数学计算。 比如Tallyfy(一个工作流软件)内建的分析工具。

所有这一切的目的是什么?我们可以总结为:相比等错误发生后再修复,通过改善流程来消除错误会更好,也更省钱。

4.任何零件采用单个供应商

你是否经常听到供应商因为质量差被抱怨? 或许你也有这样的遭遇。 你找一个价格便宜的供应商,意味着你得到的原料或者服务的质量也是“便宜”的。 你尽可以责骂你的供应商,但最终受伤害的还是你的商业信誉。

戴明指出商业主和供应商之间应该互惠互利的。 商业主应该愿意为质量付出更多。 这样的话,供应商就有足够的资源来满足商业需要。没人能在压低价格的情况下还期望用更少付出获得最多。

相反,戴明建议商业主应该和供应商建立长期的关系。 每项采购聚焦于一个供应商,这样供应商也有更多的动力来满足商业的需要,甚至付出的更多。

你也能期望更好的一致性。 或许你仍然要面对多个供应商的情况,但是供应商越多,变数就越多,质量管理也将变得越难。

供应商可以变成你持续改进过程中的一部分,但必须要以相互信任的稳定关系为前提。

5.持续改善流程,永不停止

戴明鼓励商业主应不断的分析和改进操作流程。 通过改善生产力和培训员工,把交付做到最好,同时也能提高利润。

对很多的管理者和商业主来说,这让他们畏而却步。当你以为一切都很完美时,事实却并不如此。 短期的解决方案虽然很具诱惑力,但戴明指出,我们应该追溯到商业流程的缺陷,并永久的修复它。当流程改进完成后,我们就可确保这样的问题不会再次发生。

在80年代, 对于商业主来说,特别是小商业主,要持续的关注每个流程,会相当的困难。 如今,商业流程管理软件让一切变得简单。 当你需要调整流程,只要简单的编辑下,工作流工具会自动帮你调整。

6.在工作中培训

商业主倾向于把培训当成一项昂贵的活动。不但培训本身需要费用,培训期间的工作时间也损失了。除非你精心的选择课程,你不一定会从培训中得到切实的效果。

戴明的14要点中几次提到了培训主题, 但他的重点是在工作中培训。 培训的目的是质量改善,也就是要减少变数,取得一致的、可预测的结果。

你也不希望所有流程的知识,或者部分,只有一两个人知道,这会让商业面临风险。戴明鼓励知识分享,他劝诫管理者要让员工明白他们是流程的一部分,而不是仅仅让他们干活。

在实际工作中,可以从员工入职流程开始。 如果人们知道如何去融入一个团队,自己的工作将如何的影响团队成果,他们会更关注自己的工作成果。

培训的理念也扩展到管理层级,你可以不必知道所有工作的全部细节,但你需要了解人们在做什么,你的团队面临怎样的质量阻碍。有了这些,你才能和团队一起工作,消除质量障碍。

7.运用领导力技巧

戴明认为,管理者、主管们应该关注领导力而不是传统的管理风格,后者要求严格的监督以及正规的组织结构。

戴明鼓励理解,合作和教练式管理。 一定程度的监管在商业中还是需要的,但是,和团队一起工作,发挥他们最大的潜力完成交付比惩戒式管理要有效的多。

一个领导有方的团队比只会埋头工作的团队做的更多。 他们成了质量管理团队的一部分。他们会寻求帮助,给出建议,指出你可能没注意的绊脚石。

设置目标和指标,然后去完成,这固然是不错,但是团队是否激发了自身的潜力了呢?作为一个领导者,你授权他们这样去做。你不是嘴上说说然后让别人去做,你倾听、理解、行动。 你创建一个能让人激发潜力的环境。你激励团队全力以赴,交付最好的成果。

8.驱逐恐惧

你是否曾是那个害怕老板的初级员工?又或者害怕学校里的某个老师。 在这样的状况下,你还能做到最好吗?

很多次你想提问,但因为害怕而不敢,只得闷在心里。 老板或者老师越是关注你的错误,你越会犯错。然后你想方设法掩盖这些错误, 希望不要被发现。 这就是由于恐惧导致的。 恐惧不会给质量带来好处。

上司和下属对于驱逐恐惧的必要性,应该达成一致。 员工可以自由的报告问题,会主动承认自己的错误,因为他们知道你会一起帮助解决问题,而不是采取惩罚措施。

作为一个管理者,始终定位问题,而不是人。 和员工一起找出解决方案,分享你的质量目标,让他们知道你希望达成的结果。 记住,一些最好的质量和流程改进建议来自底下的员工 - 但如果你不保持沟通畅通,就永远不会听到这些建议。

9. 打破部门间的隔阂

当人们以团队的方式工作时,能取得比单干更高的成就。 公司部门之间不可能孤立的工作。 假如产品设计者不和产品部门合作,又或者产品部与销售部之间没有沟通, 这样的组织永远不会发挥它的潜力。

没错,产品设计者并不是要变成销售人员,但是没有设计者的知识输入,销售人员并不能做到有效的销售。

产品独特的功能是什么? 又是如何满足客户需要的? 因为销售团队每天都在和客户打交道,难道设计人员在设计新产品前不应该和销售人员先聊聊吗?

同时,产品也需要成为环路的一部分。 产品团队能预料到新产品设计可能存在的问题吗? 部门之间一起合作,就可以发现潜在的问题并在发生之前消除它。

戴明推荐做法是,除了时刻把终端用户放在心里外,各部门识别出平时在沟通和服务的其他部门,把它们也当成自己的“客户”。

10.抛弃口号,鼓励个体沟通

口号听起来很漂亮,但有实际的效果吗? “我们把客户放在第一位”,听起来很棒,但实际的意义是什么呢? 它有影响到内部价值链上的每个人吗?

“更努力的工作吧”,这个怎么样? 如果你已经尽全力在做了,然后被告知还要再加把劲,会让你感觉不爽。

对警句格言能提高绩效的说法,戴明感到愤怒。 他指出口号不能解决任何的生产力或者质量问题,而是应该深入关注商业流程改进。 如果你的流程实施的好,工作就有效率,交付也会有很好的质量。

个人目标不应该泛化,戴明推荐每个人都要有自己的目标,同时设定里程牌来展示如何实现它。

简单的讲, 减少缺陷意味着找出它们在哪里发生的,怎么发生的。提高生产力意味着识别出障碍并移除它们。 在提出解决方案之前,先利用像鱼骨图这样的工具做下因果分析,找出问题的根本原因。

11.产品指标和质量不是兼容的

没错,你需要一些数字化的目标, 但对很多公司来说,设定指标被看作是领导力的体现。 在戴明看来, 高指标会让质量遭受损失。 举个例子,比如你是产品线上一名工作人员,工资是按件数结算的, 你会尽可能多的提高件数。 你尽你所能加快工作速度,但你是否还做得一样好呢?

戴明再次敦促我们聚焦流程。 一个设计良好的流程应该能交付我们希望的结果,如果不行,需要关注下流程本身。他提醒我们好的领导力会促使员工对工作产生自豪感。 员工都希望把工作做好。 现在轮到管理者来创建一个环境,让他们能这样去做。

数字会带来价值吗?它们不会。 它们应该用来衡量流程,而不是人。

一些善于思考的人认为数字可作为激励因子, 特别是在销售领域, 但目标管理法应该谨慎使用。当你设定了一些数字化目标,你是否在鼓励人们走捷径?这肯定会影响到质量。 你更倾向于哪些激励行为? 记得,你衡量什么,你就得到什么。

最后,假如你想设立一个数字目标, 你需要明确的知道,它能够实现。没有相应的计划和方法,单纯的数字是没有意义的。

12. 移除障碍

戴明相信工作的自豪感对质量和流程改进是很关键的。 你自己可能也有体会。 当你做喜欢的事时,你会做得更好,结果也往往令人满意。 但如果人们经常批评你并且把你和别人比较,你不再享受之前喜欢的工作了。

总有一些员工获取技能比别人快,并且取得更好的成就。这是很自然的。 这是好事,团队中的其他人不应该觉得自己会被人说三道四,或者感到自身价值不如别人。 戴明说质量体系最终会让每个人工作在同一标准下。

流程问题也会导致工作受挫。 你希望交付产出物X,但需要依赖Y和工具Z,Z会帮你更轻松的完成工作。 如果你没有Y和Z, 交付X就变成了噩梦。 你会去抱怨吗? 不,这时需要修复流程中的问题,让你能获得你需要的输入和工具。

我们再来类比下。 去年,因为流程的缺陷,你的工作一直很不顺。 在绩效考评的时候,数据显示你的工作几乎是不可接受的。你对目前的工作还会有多少的喜欢? 同时,一个经常犯错误的同事,却因为数据好看得到了晋升。

戴明给管理者出了个难题。 作为一个领导者,你的任务是创建一个可行的体系来帮助别人更好的工作。 如果有人掉出了体系之外,你必须纠正它, 但如果他们的工作是在体系范围之内,你需要和他们一起找出体系本身的问题。

13. 鼓励教育和自我提升

当戴明谈及“工作中培训”优先时, 他也提倡通过持续教育来实现个人成长。 当人们在学习工作或者业务相关的知识时,他们的技术得到改进,也能更好的面对当前和未来的商业挑战。

就像锻炼让身手更敏捷一样, 教育帮我们改善思维方式。 选择什么样的教育取决于你,但假如你的雇员想在其他领域提升自己,你能想办法支持他们,也是非常棒的。 记得,你的业务不总是维持不变的,雇员获得的新技能可能会在将来派上用场。

企业拥有的技术集质量越好,戴明说,产品和服务的整体交付质量也就越好。

14. 每个人的工作都可以转换

戴明指出如果想改善质量或生产力,需要观察的是体系不是人。但如果是寻找解决方案,他提倡应该尽可能多的从生产一线的人员获取信息。

他建议利用业务流程图来描述流程。接下来,可以让人们思考如何改变流程来提高产品的质量。因为流程中的每一步都会影响后续的活动, 每个人都要做好转换工作的准备。

最后,当要实施变革时, 团队已经做好了准备。 成员可能会发现一些额外的优化方案,他们会大胆的分享。 现在,良好的持续改进文化氛围开始形成了,并且前途一片光明。

戴明的14要点应用实践

戴明没有详细的介绍如何影响变化,但他的理念在世界商业中已经产生了深远的影响。从实践的角度,把戴明14要点作为第一理念将会导致改变 - 一个变得更好的改变

利用像Tallyfy这样的工作流软件, 实现基于戴明思想的流程会变得更简单。员工通过Tallyfy接受流程任务的工作指导时,无需记得流程的每个变化和调整。当你和你的团队觉得这样或那样的细节可以变得更高效,要更改流程也是非常简单的。

Tallyfy可以把戴明的14要点应用到实践中,并且持续的改进。 (全文完)

Read More

docker部署zabbix

前言

zabbix的安装,有源码安装,yum安装,docker方式安装这几种方法,一般常采用yum方式安装,很方便。如果你对docker感兴趣,可以尝试docker方式安装。各种安装的方法官网上的文档写的已经非常详细了。我看了下docker安装对应的docker-composer.yml配置文件,的确非常全面,但对于初学者来说,很多配置都用不上,而且缺乏相应的说明,让人有点迷糊。

官网docker安装文档:https://www.zabbix.com/documentation/4.4/manual/installation/containers

本文参考网上的资料,结合自己的实际操作,整理了一份简化版的docker-composer.yml,并对关键的配置项做了说明。

环境准备

宿主机:基于Hyper-v创建的centos7虚拟机,主机名为:laptop-centos。已经装好docker环境和docker-composer。

zabbix镜像

本次安装需要如下三个镜像:

  1. zabbix/zabbix-server-mysql:lastest - mysql版的zabbix server
  2. zabbix/zabbix-web-nginx-mysql:latest - mysql版的zabbix web包,集成了nginx
  3. mysql:5.7 - mysql 5.7数据库
  4. zabbix/zabbix-agent:lastet - zabbix agent

如果需要安装proxy,镜像为:zabbix/zabbix-proxy-mysql:latest,这次没有安装。

docker-compose.yml配置

yaml文件对格式要求比较严格,用空格来缩进,同级别的缩进量要一致。

  1. mysql安装:

yaml配置如下:

version: '3'
services:
  zabbix-mysql:
    image: mysql:5.7
    # 容器名,相当于主机名,其他容器通过该名字访问mysql服务
    container_name: zabbix-mysql
    # 网络模式:采用默认的网桥模式
    network_mode: bridge
    ports:
        - "3306:3306"
    command: [
        '--character-set-server=utf8',
        '--collation-server=utf8_bin',
    ]
    # mysql启动时会创建zabbix用户和zabbix数据库
    environment:
        - MYSQL_USER=zabbix
        - MYSQL_DATABASE=zabbix
        - MYSQL_PASSWORD=zabbix
        - MYSQL_ROOT_PASSWORD=zabbix
        - LANG=en_US.utf8
        - TZ=Asia/Shanghai
    restart: always
  1. zabbix-server安装

docker-composer默认的网络模式是bridge,zabbix服务如果采用bridge网络,就有独立的ip和主机名,后面涉及服务器地址的配置都要以容器的主机为准,不能配置宿主机的地址。网上说这种模式无法监控tcp端口,因此我们采用改成host网络模式。host模式表示容器和宿主机共享一个ip。

zabbix-server:
    container_name: zabbix-server
    image: zabbix/zabbix-server-mysql:centos-latest
    restart: always
    # 因为zabbix采用的是host模式,和mysql容器不在一个网段,无法直接访问
    # 宿主机配置了3306端口映射,所以这里的db_server_host要写宿主机名。
    # 数据库信息会自动写入到zabbix_server.conf文件中
    environment:
        - DB_SERVER_HOST=laptop-centos
        - MYSQL_DATABASE=zabbix
        - MYSQL_USER=zabbix
        - MYSQL_PASSWORD=zabbix
        - MYSQL_ROOT_PASSWORD=zabbix
        - TZ='Asia/Shanghai'
    ports:
        - "10051:10051"
    # 设置网络模式为host
    network_mode: host
    # 如果MySQL没起,会先启动mysql
    depends_on:
        - "zabbix-mysql"
  1. zabbix web端安装
zabbix-web:
    image: zabbix/zabbix-web-nginx-mysql:latest
    container_name: zabbix-web
    restart: always
    network_mode: bridge
    ports:
        - "8080:80"
    environment:
        - DB_SERVER_HOST=laptop-centos
        - MYSQL_DATABASE=zabbix
        - MYSQL_USER=zabbix
        - MYSQL_PASSWORD=zabbix
        - MYSQL_ROOT_PASSWORD=zabbix
        - PHP_TZ="Asia/Shanghai"
        - TZ='Asia/Shanghai'
    depends_on:
        - "zabbix-server"
        - "zabbix-mysql"
  1. zabbix-agent 安装
zabbix-agent:
    image: zabbix/zabbix-agent:latest
    container_name: zabbix-agent
    #zabbix服务器名要写宿主机名,如果采用bridge模式,就写容器名。
    environment:
        - ZBX_HOSTNAME=laptop-centos
        - ZBX_SERVER_HOST=laptop-centos
        - ZBX_SERVER_PORT=10051
        - TZ='Asia/Shanghai'
    # 网络模式也是host
    network_mode: host
    ports:
        - "10050:10050"
    depends_on:
        - "zabbix-server"
    restart: always
    privileged: true

启动

进入docker-compose.yml所在目录,敲入命令:docker-compose up -d

-d 表示后台运行,调试期间不用加-d,方便看日志。

Read More

配置即代码 IN ACTION

Jenkins提供的可视化操作界面,为初学者提供了方便。但如果要频繁的创建、配置任务,通过界面操作,效率总是太低,不如脚本来得快捷。

最近在为一些运维项目搭建部署流水线,每个项目都需要十几个jenkins任务,有的甚至更多。如果通过界面一个个去配置,也挺繁琐的。按照SRE的原则,重复的配置工作属于琐事的范畴,应该尽量避免。

再者,按照配置即代码的原则,配置信息也需要纳入版本管理。而通过UI配置的jenkins任务,所有的信息都在服务器上,不好做版本管理。

本文主要是对最近工作的一个总结,主要解决2个问题:

  • 利用命令行工具创建jenkins任务。
  • 通过pipeline实现配置版本化管理。

利用命令行工具创建jenkins任务

打开“系统管理”->“Jenkins命令行接口”,如下图: 通过UI完成的操作,很多也能通过命令行来做,如任务/视图的增删改、任务运行等等。

  1. 下载jenkins-cli.jar到本地,确保本地环境安装了jdk。

  2. 准备任务模板文件, create-job命令需要一个xml文件,先通过UI界面创建一个示例任务job-template,把主目录/jobs/job-template/config.xml文件复制出来,作为模板文件。主目录具体的路径可通过“系统管理”->“系统设施”里查看。

  3. 修改模板文件并创建任务 修改xml中相关的值,如git地址,部署目录等。然后利用以下命令创建任务: java -jar jenkins-cli.jar -auth user:pass -s http://jenkins-server:port/jenkins/ create-job job-name < job-name.xml 其中: user:pass: 登录jenkins的账号密码 job-name:待创建任务的名称 job-name.xml:根据模板修改的xml文件

不足之处:

  • 项目的部署流程要求与示例任务相似,不然xml修改起来比较麻烦。
  • xml文件不利于后期的更新维护。

利用pipeline实现配置即代码

pipeline实现了部署流程和job的解耦,把配置信息放到一个叫jenkinsfile的文件里。 jenkinsfile放到版本库中统一管理。任务运行时,jenkins从scm获取最新的jenkinsfile文件,然后按照配置的内容运行相关命令,比如构建,打包等等。

这样,各项目的任务xml文件就变得相当简单,唯一需要修改的就剩下jenkinsfile的scm地址了:

如何创建pipelne请参考相关的文档,这里提供一个jenkinsfile的示例:

pipeline {
  agent any 

  stages {
    // 准备阶段,从git拉取代码
    stage("Preparation") {
      steps {
        git 'https://project-git-address.git'
      }
    }
    // 编译,打包阶段,利用mvn命令生成部署包
    // $profile为参数,从命令行传入
    stage("Build") {
      steps {
        sh "mvn clean package -P$profile"
      }
    }
    // 部署阶段:在远程deploy sever上执行deploy.sh脚本,
    // deploy.sh位于/root目录下。
    //脚本功能是从jenkins server获取jar包,然后部署到指定目录,并启动服务
    stage("Deploy") {
      steps {
        script {
           def remote = [:]
            remote.name = deploy server name'
            remote.user = 'root'
            remote.host = "deploy server ip"
            remote.port = 22
            //服务器是采用私钥登录的,这里需提供私钥文件
            remote.identityFile = '/root/.ssh/xxx.private'
            //如果采用账号登录,则提供登录账号信息
            //remote.account = 'root'
            //remote.password = 'xxxxx'
            remote.allowAnyHosts = true
            sshCommand remote: remote, command: "deploy.sh"
        }
            
      }
    }
  }
}

配置完成后,可通过以下命令运行该任务:

java -jar jenkins-cli.jar -auth user:pass -s http://jenkins-address/jenkins build *job-name*  -s -v -p profile=dev|prod
  • 如果觉得密码采用明文不安全,也可用jenkins生成的token代替。
  • -p key=value [-p key2=value2],如果任务有参数,可以通过这种形式输入。
Read More

拆书凤凰项目- 部署管道

经历了几个通宵,凤凰项目终于上线了,但部署的问题依然很严重,上周的一个变更部署,又花了一个通宵。总结会上,埃里克指出了问题的所在:虽然已经改善了工作流,但批量规模太大,部署涉及到太多方面,引发计划外的修复。需要建立起从IT运维部返回至开发部的不间断的反馈回路,在初始阶段就筹划产品的质量。

“如果每九个月才能打一发炮弹,就永远射不中你们瞄准的目标。别再去想那些内战时期的大炮了,想想高射机枪吧”。埃里克继续说道,“在任何一个工作系统里,理论上的理想状态是单一工作流,这样能让生产能力最大化,同时让变化幅度最小化。通过持续不断地降低批量规模,就能达到这种状态。”

开发总监克里斯说,连一个次要的漏洞修复部署都问题重重,我们无法承受每月一次的发布。我建议改成二个月发布一次。

这遭到了CEO斯蒂夫的反对,离购物季还不到30天时间了,由于延迟了很多的功能,预期的销售收益没有实现。我们没有时间了。

比尔理解克里斯的想法,要让笨重的凤凰项目起飞,的确不太可能。为了实现预期销售目标,比尔提议,组建一支特别行动队(Special Weapons and Tactics team,简称SWAT),叫他们去弄清楚,哪些功能可以帮助我们尽快达到收入目标。时间不多了,所以我们得谨慎选择功能。我们要告诉他们,为了完成这项工作,他们可以打破各种规则。这个建议得到了大家的认同。

究竟如何降低批量规模,实现快速的部署?比尔心里还是没谱,只好再次求教埃里克。埃里克又把比尔带到了MRP-8工厂,指着地面上的一长列设备说,那里的两道工序(喷涂、烘干)曾经是工作流的瓶颈,由于每项工作的准备时间很长,只好依靠巨大的批量规模来满足需求,把尽可能多的部件塞入烘房。但却无法满足客户的需求,即使客户愿意加钱,我们也无能为力。我们明白要提高生产力,必须降低批量规模,但每个人都说那是不可能的。

丰田公司的“快速换模”,为我们提供了思路。我们改良了流程,把四个工作中心合而为一,排除了三十多个容易出错的人工步骤,使整个工作周期完全实现了自动化,形成了单一工作流,并且去掉了所有的准备时间。生产能力一飞冲天。

“现在,轮到你了。”,埃里克指着比尔说,“你得想出办法来降低转换时间,让部署周期时间加快。”

“要怎么做?”,比尔还是一头雾水。

“把布伦特派到特别行动队中,和克里斯一起想想办法,如何才能保证在敏捷开发流程的每一个阶段,不仅有可推出的代码,还能具备能够部署这些代码的工作环境!”。埃里克严厉的说,“只要开发部和运维部协同工作,连同QA和业务部门一起,这个‘超级部落’就能够成就各种不可思议之事。”

“你们需要创建‘部署管道’,那是从代码签入到投产的整个价值流。那不是一种技术,而是生产。你们应该对所有东西都进行版本控制。所有东西,不只是代码,而是创建环境所需的每一样东西。然后,你们应该把整个环境创建流程自动化。在部署管道中创建测试和生产环境,然后彻底按照要求往里面部署代码。那样你们才能缩短准备时间并排除故障,才能随时跟上开发部的各种工作节奏。”

回到团队,比尔表达了埃里克1天10个部署的要求,每个人都觉得那是天方夜谭。问题出在哪里呢?为了弄明白部署流程,大家把部署所涉及的所有步骤都列在了白板上。从代码提交开始,也就是说整个流程包括了开发,测试以及运维的工作。流程优化必须从整个价值链出发,局部的优化没有意义。

比尔望着白板上几十个方框,让他联想到了工厂的工作中心,这不就是工厂的流水线吗?IT工作本质上和工厂是一样的,就是要打造一条价值流。这大概就是埃里克所说的部署管道吧。

现在,这条管道还体现不出价值,基本上每个环节都存在问题。但团队已经找到了思路,利用精益的方法,结合布兰特之前写的一些自动化脚本,自动化部署也不是那么遥不可及了。

Read More

why developers should also be on call

一切都围绕反馈环

很多开发人员都熟悉持续交付管道,它是一个相互协作的过程,反馈环存在于过程的每个阶段。 产品、开发和QA一起定义新功能,开发人员利用TDD完成功能开发。TDD本身就是一个反馈环,通过不断的测试来指导开发进程。代码在主干上编译,运行单元测试。 接着应用会部署到测试环境,进行一系列验收测试。所有这些反馈不断的为生产环境部署提供信心。测试完成后,开发人员把部署工作交接给运维,然后开始新一轮的功能开发。

看起来没毛病,很符合我们的思维习惯,但并不正确。问题在于开发人员过早从交付管道中退出,把工作扔给了墙外的团队,反馈因此中断了。

把墙拆掉

要构建可靠、贴心的应用,获取应用在部署/运行中的反馈是非常重要的。从管道构建开始,我们一直都依赖反馈环,但是应用一旦部署成功,反馈环似乎被丢弃了。 代码的价值只有被终端用户使用才能体现出来,用户的反馈是所有反馈中最重要的,但是我们作为开发者,却没有收到。

可能是组织级的原因导致了隔离:传统的做法都是开发写代码,运维维护服务。 Devops提出了一种新的文化,让开发和运维走的更近。比如,开发能及时获取生产环境的反馈。 生产日志分析是开发获取反馈的一种方式。通过错误信息能洞察系统的薄弱环节,并持续完善。

洞察系统的另一种方式是建立指标采集服务。指标可以来自系统本身,也可以根据业务需求来定。 比如,信用卡和借记卡数量比这个指标,数据很容易采集,可用来解答这样的问题:“从特定的api端点上接收了多少请求,是否可以取消?”(其实我也没看懂!)。指标以百分比的方式采集,除异常点,让反馈专注于主要的用例,而不仅仅是告警。

这些自动记录的反馈几乎可以实时的获取,要完善系统的心智模式,还有很长的路要走。离完全拥有应用也还有一定差距。

更努力,更好,更快,更强

开发人员对自己开发的应用有完全的控制权,并且直接负责应用的运行。提供了另一种视角来审视“什么是重要的”,“需要关注什么,哪些不需要关注”。开发过程中看起来微不足道的问题,到了运维阶段,可能会影响你的个人生活,特别是当你的电话响起时。 偶尔的内存泄漏在白天不是什么问题,只要重启服务就可。但如果出现在晚上,就完全是另一回事了。 都知道显示错误页面是一个很不好的用户体验,由于简单的重启能解决,从而忽视了从根源上解决问题。现在,到你还债的时候了,不得不优先处理这些运维问题。

开发人员轮值是指标驱动开发的演进,当应用发生错误时,开发人员通常是最清楚如何来解决的。 随着应用上云和硬件基础架构的成熟,应用错误会比基础设施问题更多。 当微服务普及,消息成了服务之间的粘合剂,就需要开发人员的系统知识来定位根源,让应用尽快的恢复正常。

驱动力有三大要素:自主、专精、目的。拥有完全的自主权,才会有目的,并驱使自己精通相关知识让系统变得更好,自主决定修复优先级。我相信,这样的自主权,让我们对构建的应用感到自豪。


It’s all about Feedback Loops The Continuous Delivery Pipeline is familiar to most developers. It’s a collaborative process built upon loops of feedback at every stage. A new feature will defined between a Product Manager, a Developer and a Quality Analyst. A pair of Developers will work together on the implementation following a Test Driven Development approach using the tests as feedback to guide progress. The new code is compiled with the master branch and all of the unit tests are run. The application may be deployed to a test environment and a series of Acceptance Tests will be run. All of this feedback gives the confidence to proceed to a Production deployment at which point Ops take over and the developers pick up a new change.

This is wrong. The Developers’ involvement stops too soon. The change is thrown over the wall to another team and the feedback cycles stop.

Bring down the wall The feedback from the deployment itself and from the running application are vital for building a reliable and fit for purpose application. In all other parts of the process we rely on feedback loops, but there is a tendency to drop this once the code is deployed. It is only in Production, when the code is in the hands of the users, that any code matters. It is this feedback which is the most important of all and yet, we as Developers, are not receiving it.

There could be organisational reasons for this separation – traditionally Developers write code and Operations maintain running services. We are all aware that DevOps is a cultural shift to bring these two areas closer together and part of this includes Developers being involved in the feedback from Production. Collating and aggregating log files is a way of getting some of this feedback to the Developers. Log data gives an insight into errors that improves debugging and highlights weak areas in the application.

Adding a metrics collection service provides another insight into the running application. Data points can be sent from the any part of the application and can be written around business requirements, for example the number of credit card payments vs debit card. They are simple to add and can be used to answer questions such as “how many requests to we receive to a particular API endpoint, and can we deprecate it?”. Metrics values can be rolled up into percentiles and outliers smoothed away allowing feedback to focus on the majority use cases, not just alerts.

All of this telemetry feedback can be received in near real-time and goes a long way to improving the mental models we’ve built up of the production system. But, it is still a step removed from fully owning the application.

Harder, Better, Faster, Stronger

Owning and being directly responsible for the successful execution of something you build gives a different perspective as to what is important, what needs focus and what does not. Issues that seem trivial in development become far more important to you personally when it’s your phone which rings. Random memory leaks that require app reboots are easy to ignore when they occur during the day, but not so much when they happen during the night. You’ve always known that this affects the users – that they have a terrible experience when they see the error page – but it was always difficult to track down and service so easily restored. But now you feel the pain too and prioritise the operational fixes.

Developers On Call is an evolution of Metrics Driven Development When it comes to application errors it is the Developers who generally have the greatest context for fixing things. As applications move to the cloud and on-premise infrastructure matures, over time application errors become more frequent than infrastructure ones. As microservices become more common and messaging becomes the glue, it will take the Developers’ system knowledge to isolate the cause and get things running again as quickly as possible.

It is this level of ownership which brings the purpose in the driving forces of Autonomy, Mastery and Purpose. Combined with the desire to master the knowledge needed to make the application successful and the autonomy to prioritise operational fixes. I believe it is this ownership which enables us to have pride in the systems we build.

Read More