精华内容
下载资源
问答
  • 缓存、代理、队列 设置 克隆这个 repo,运行npm install 。 安装 redis 并在 localhost:6379 上运行 来自 。 这可以在具有端口转发的 6379 上具有开放端口的 VM 上完成: ...tar xvzf redis-stable.tar.gz ...
  • Dev Ops 作业 2 - 测试套件最小化 统一 ID : apatwar 覆盖率报告
  • DevOps作业要求

    2015-02-15 21:05:00
    DevOps 作业要求:   请仔细阅读题目的要求,并编写一些程序来创建、配置部署环境并部署相应的软件包。如果你提交了多份解决方案,我们将只评价一种。对于程序语言,我们期望你使用 puppet 、 chef 、 ...

    DevOps作业要求:

     

    请仔细阅读题目的要求,并编写一些程序来创建、配置部署环境并部署相应的软件包。如果你提交了多份解决方案,我们将只评价一种。对于程序语言,我们期望你使用puppetchefansible或者powershell,甚至是rubypython等。

     

    你不能使用外部的程序库或者其他人实现的模块来解决问题,但是你可以使用外部的工具来构建测试环境或者进行测试。特别地,你可以使用相应的单元测试工具或者环境构建工具(比如,beakerkitchencucumber或者ec2-toolsvagrantdocker)。

     

    如果你没有提供部署环境的创建脚本,请提供一个简单的环境要求说明,比如操作系统、版本号等,但请不要提供详尽的部署文档。

     

    我们将只认你的程序,并将会在本地干净的环境上使用你提交的程序进行测试。我们期待的结果是执行几个命令、尽可能少的手工操作就能完成所有软件包的配置部署。详尽的部署文档,或者将配置内容放在操作文档里面并不符合我们的要求。你的程序并不需要尽善尽美,但一定是可以运行、易于维护扩展的。


    转载于:https://my.oschina.net/kcw/blog/378852

    展开全文
  • <p>My Gitlab CI Auto DevOps job failed with <pre><code>Status: Downloaded newer image for gliderlabs/herokuish:latest -----> Unable to select a buildpack ERROR: Job failed: exit code 1 </code></...
  • DevOps家庭作业1 采取的步骤 的脚本文件DigitalOcean-digitalOceanMain.js AWS-awsMain.js 包装脚本-mainScript.js 适用于Ansible的Playbook-playbook.yml 列出package.json中的所有依赖项,并使用安装它们 npm ...
  • 在家工作 这是DevOps HomeWork。
  • Devops Homework-1设置和配置服务器 该存储库主要旨在提供说明,以使用诸如DigitalOcean和Amazon AWS之类的服务提供商在远程VM上配置和配置服务器。 目前,这是作为NC州CSC 591 Devops课程的HW-1的一部分完成的。 ...
  • ##作业2 ### Coverage Screenhot
  • #硬件 4 ##先决条件 您将需要以下内容: Redis - 你可以得到它,你会希望它在全球范围内安装。 如果您使用的是 OSX 并且安装了自制软件,最简单的方法是使用以下命令: brew install redis npm/nodejs - 你可以...
  • DevOps家庭作业 1.编码 请编写一个小的工具,列出一个AWS账户中的所有S3存储桶。 该工具返回存储桶的名称和创建时间就足够了。 规则: 您可以自由使用自己选择的编程语言和SDK。 安装不应要求我们安装外部工具。 ...
  • SEZG514-Assignment1 DevOps SEZG514作业简介1
  • devops-with-k8s-源码

    2021-03-26 19:43:04
    与k8s一起玩 带K8s课程的DevOps作业
  • 此存储库是作为公司DevOps课程一部分进行的作业而创建的 当您完成任务时,我将在README.md中添加完成工作的描述,遇到的问题以及如何解决这些问题,以及我从中获得灵感的有用链接。 :smirking_face: 开始吧! 准备...
  • 安徒生 Andersen DevOps课程的家庭作业 AlexP-hw: Alexander P. Folder的出色任务,包含Bash脚本,Git,Ansible的作业。 任务1-1:第一个作业,第一个任务 任务1-2:第一个作业,第二个任务
  • 开发人员分配 Shanmugapriya的作业1-2020MT93084
  • 为什么需要 devops 2 2020/3/1 Devops 的理念 上云能力 80% 预计到 2020 年全球 80% 的应用都将实现云端部署 公有云 / 私有云 DevOps 作业能力 分布式环境 管理能力 46% 2016 年 46% 的企业在寻求采用分布 式的...
  • 2018年 大四学年 DevOps课程的大作业——OnlineES在线考试系统 使用IDEA进行开发,数据库IP地址写在了配置文件中,项目的架构是微服务架构,使用Spring+Maven构建项目。 jar文件等未上传,可使用Maven自动生成,在此...
  • 作业1 软件SC313004软件工程-DevOps和CI / CD第1节613021009-2
  • devops 项目经理问题陈述:(Problem Statement:) Deploy Webserver using the best Principles, Tools, Techniques of DevOps Culture. 使用DevOps Culture的最佳原则,工具和技术部署Web服务器。 解决方案的简要...

    devops 项目经理

    问题陈述:(Problem Statement:)

    • Deploy Webserver using the best Principles, Tools, Techniques of DevOps Culture.

      使用DevOps Culture的最佳原则,工具和技术部署Web服务器。

    解决方案的简要说明: (Brief Explanation of Solution:)

    Here I am using Ansible for the configuration management system, Jenkins for CI/CD, Jenkins with Multi-Node Cluster, Build Jobs using DSL Code of Jenkins, for production I am using one of the famous services of AWS,i ,e AWS EKS(Elastic k8s Service).

    在这里,我将Ansible用于配置管理系统,将Jenkins用于CI / CD ,将Jenkins用于多节点集群,使用Jenkins的DSL代码构建作业,用于生产,我正在使用AWS的一项著名服务,即AWS EKS (弹性k8s服务)。

    先决条件: (Prerequisite:)

    • Linux OS(Redhat, Centos).

      Linux操作系统(Redhat,Centos)。
    • Have an AWS account.

      有一个AWS账户。
    • Created IAM users with AdministratorAccess Permission.

      已创建具有AdministratorAccess权限的IAM用户。
    • AWS CLIv2 configured in Linux with IAM user.

      在Linux中使用IAM用户配置了AWS CLIv2。
    • kubectl, eksctl configured in Linux.

      kubectl,在Linux中配置的eksctl。
    • Ansible, Git installed in Linux.

      Ansible,在Linux中安装了Git。

    步骤1)开发网站代码: (Step-1)Developing website Code:)

    Image for post
    The developer develops the code
    开发人员开发代码
    Image for post
    Code pushed in Github
    在Github中推送代码

    Note: Here one point, here we need one Dockerfile for building our docker iso for a webserver.

    注意:这里有一点,这里我们需要一个Dockerfile来为网络服务器构建docker iso。

    Image for post
    Dockerfile
    Docker文件

    Explanation of Docker: Here my Dockerfile copy all the code in the respective image for building iso for our webserver.

    Docker的说明:在这里,我的Dockerfile复制了各自映像中的所有代码,用于为我们的Web服务器构建iso。

    现在,DevOpsTeam的时机已经到来,可以使用最佳实践,工具,技术等来部署此代码。 (Now The time for DevOpsTeam has come to deploy this code using best practices, tools, techniques, etc.)

    步骤2)准备好安装程序。 (Step-2)Getting setup ready.)

    • Here I am using Jenkins on top of docker, for setting up Jenkins , and we have to first install docker in OS, So for the Configuration Management System, I am using Ansible-Roles.

      在这里,我在Docker之上使用Jenkins来设置Jenkins,我们必须首先在OS中安装docker ,因此对于配置管理系统,我正在使用Ansible-Roles。

    Image for post
    Ansible-config file
    Ansible-config文件
    • Here my ansible roles path and all the things are configured.

      在这里,我的角色角色路径和所有事物都已配置。
    Image for post
    Ansible-roles
    Ansible角色
    Image for post
    Ansible-Role Code.
    角色扮演代码。
    • To run this code we have to create one playbook and use this role in that playbook.

      要运行此代码,我们必须创建一个剧本并在该剧本中使用此角色。
    Image for post
    Ansible-Playbook
    Ansible剧本
    • Code of Ansible-Playbook:

      Ansible-Playbook的代码:
    - hosts: localhost
    roles:
    - docker_rehl8
    • to run this playbook type:

      运行此剧本类型:
    ansible-playbook FILE_NAME.yml

    角色和剧本的解释:在这里,我首先使用yum_repository模块为docker配置yum,此后,我使用命令模块安装docker,当所有安装完成后,我已经创建并拖入hub.docker.com詹金斯iso。 只有我需要拉入操作系统,因此我使用了一个模块从hub.docker.com中拉出我的Jenkins iso (Explanation of Roles and playbook: Here I and first configuring yum using the yum_repository module for docker, and after that, I install docker using the command module, and when all installation completed, I have already created and pull into my hub.docker.com of Jenkins iso. Only just I need to pull in my os, so I used a module for pulling my Jenkins iso from hub.docker.com)

    Dockerfile of Jenkins:

    Jenkins的Dockerfile:

    FROM centos
    RUN dnf install wget -y
    RUN wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat-stable/jenkins.repo
    RUN rpm --import http://pkg.jenkins.io/redhat-stable/jenkins.io.key
    RUN dnf install java-11-openjdk.x86_64 jenkins -y
    RUN dnf install -y openssh-server
    RUN dnf install net-tools -y
    RUN dnf install git -y
    RUN dnf install httpd -y
    RUN dnf install which -y
    RUN dnf install python36 -y
    RUN pip3 install ansible
    RUN echo "jenkins ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
    RUN echo "java -jar /usr/lib/jenkins/jenkins.war &" >> /root/.bashrc
    RUN bash

    输出: (Output:)

    Image for post
    Jenkins iso
    詹金斯iso
    Image for post
    docker installed by ansible-roles
    由ansible-roles安装的docker
    Image for post
    Jenkins-iso pulled by ansible-roles
    詹金斯-iso被ansible-roles拉动

    步骤3)Jenkins设置。(Step-3)Jenkins Setup.)

    • Only just we need to start Jenkins container, type:

      只需要启动Jenkins容器,输入:
    docker run -it --name jenkins1 -p 8082:8080 -v /root/jenkinsdata/:/root/.jenkins rootritesh/jenkins:v1
    • Here they starting container and exposing port 8080 of Jenkins, for making data persistent I mount Jenkins location on /root/jenkinsdata.

      他们在这里启动容器并暴露Jenkins的端口8080,以使数据持久化,我将Jenkins位置安装在/ root / jenkinsdata上。
    • Now configuring Jenkins:

      现在配置Jenkins:
    Image for post
    • Copy-paste the password from the terminal.

      从终端复制并粘贴密码。
    Image for post
    • No need to install plugins right now, close it.

      无需立即安装插件,将其关闭。
    Image for post
    Jenkins is ready
    詹金斯准备好了

    步骤4)在Jenkins中安装插件。(Step-4)Installing plugins in Jenkins.)

    • Go to Manage Jenkins>Plugin Manager.

      转到管理詹金斯>插件管理器。
    Image for post
    • install these plugin > GitHub, job DSL, pipeline.

      安装这些插件> GitHub,作业DSL,管道。
    • Click on install without restart

      单击安装而不重新启动
    Image for post

    步骤5)配置Jenkins(Step-5)Configure Jenkins)

    • Here I using Jenkins Multi-Node Cluster, For configuring it Goto configure> Node> New Node> Add a new Node.

      在这里,我使用Jenkins多节点集群,要对其进行配置,请转到配置>节点>新节点>添加新节点。
    • Here I am using two nodes one for Developer job building and another for DevOps team.

      在这里,我使用两个节点,一个用于开发人员工作,另一个用于DevOps团队。
    • Now in the AWS launch one ec2 and configure it:

      现在在AWS中启动一个ec2并进行配置:
    $sudo su -- root
    $yum install git -y
    #yum remove java-1.7.0-openjdk -y
    $yum install java-1.8.0 -y
    $yum install docker
    $docker login (type username and password)
    $docker pull centos.
    $docker pull rootritesh/webserver-php
    • We need this configuring for a dev job.

      我们需要为开发作业进行此配置。
    Image for post
    AWS ec2
    AWS ec2
    • For the first Node, I am using AWS EC2.

      对于第一个节点,我正在使用AWS EC2。
    Image for post
    • Give the credential > Select kind > SSH Username with private key > give username (ec2-user) > Private key > Add it

      提供凭据>选择种类>带有私钥的SSH用户名>给出用户名(ec2-user)>私钥>添加它
    Image for post
    • Save it.

      保存。
    • The output of the AWS Node.

      AWS节点的输出。
    Image for post
    AWS node is Connected
    AWS节点已连接
    • Second Node which my Base Os of Linux where all things are configured like=> AWS CLI, eksctl, etc.

      第二个节点,我Linux基本操作系统中配置了所有内容的=> AWS CLI,eksctl等。
    Image for post
    Linux node
    Linux节点
    • For credentials of Base, OS Linux, Connect vi ssh >provide username and password

      对于Base,OS Linux的凭据,请连接vi ssh>提供用户名和密码
    • Save it.

      保存。
    • The output of the Linux Node.

      Linux节点的输出。
    Image for post
    Linux Node Connected Successfully
    Linux节点连接成功
    • Now after that, we need to configure our Email Notification in Jenkins.

      现在,在此之后,我们需要在詹金斯中配置电子邮件通知。
    • When our Job fails Jenkins Automatically sends the email to the team.

      当我们的工作失败时,詹金斯自动将电子邮件发送给团队。
    • Go to Manage Jenkins > Configure System.

      转到管理Jenkins>配置系统。
    • At the bottom there option E-mail Notification.

      在底部,有电子邮件通知选项。
    Image for post
    E-mail Notification
    电子邮件通知
    • It is working, test configured successfully.

      它正在工作,测试配置成功。

    步骤5)詹金斯DSL作业 (Step-5)Jenkins DSL JOB)

    • Make one freestyle job name jobdsl.

      使一个自由式作业名称为jobdsl。
    • Configure it using the following groovy DSL code.

      使用以下常规DSL代码对其进行配置。
    Image for post

    码: (Code:)

    job('devjob') {
    scm {
    github('rootritesh/DevOps_Project')
    }
    triggers{
    scm("* * * * *")
    }label('aws')steps {
    shell('''
    sudo su -- root
    pwd
    sudo docker build -t rootritesh/myproserver:v8 .
    sudo docker push rootritesh/myproserver:v8''')}
    }job('prod') {
    label('kube')steps {
    shell('''
    wget https://raw.githubusercontent.com/rootritesh/AWS-EKS-TASK/master/cluster.yaml
    eksctl create cluster -f cluster.yaml
    sleep 5
    kubectl get pods
    if kubectl get deployments | grep myweb
    then
    echo "Webserver is running"
    kubectl describe deployment myweb
    else
    kubectl create deployment myweb --image=rootritesh/myproserver:v8
    kubectl scale deployment myweb --replicas=5
    kubectl expose deployment myweb --port=80 --type=LoadBalancer
    fi''')}
    }job('status') {
    label('kube')
    triggers{
    scm("* * * * *")
    }steps {
    shell('''
    if kubectl get deployment | grep myweb
    then
    echo "Deployment is There"
    else
    exit 1
    fi
    ''')
    }
    publishers {
    mailer('rootritesh34@gmail.com', false)
    }
    }

    Explanation: Here I am using Jenkins DSL Groovy language for configuring jobs.

    说明:这里我使用Jenkins DSL Groovy语言来配置作业。

    步骤6)配置Jenkins管道作业。 (Step-6) Configure Jenkins Pipeline Job.)

    • Make one Pipeline job name MYAL.

      使一个管道作业名称为MYAL。
    • Configure it, using the following code.

      使用以下代码对其进行配置。
    Image for post
    Jenkins Pipeline Job
    詹金斯管道作业

    码:(Code:)

    pipeline {
    agent anystages {
    stage('Dev') {
    steps {
    echo 'building dev jobs'
    build job: 'devjob'
    }
    }stage('Prod') {
    steps {
    echo 'building production world'
    build job: 'prod'
    }
    }

    stage('checking status') {
    steps {
    echo 'status'
    build job: 'status'
    }
    }
    }
    }

    Explanation: This Pipeline job is running one by one job which is configured

    说明:该管道作业正在配置的一个作业中运行

    步骤7)运行作业DSL(Step-7)Run Job DSL)

    • Goto jobdsl job and build it.

      转到jobdsl工作并进行构建。
    Image for post
    • Build it.

      建立它。

    Output of jobdsl

    jobdsl的输出

    Image for post
    Job build
    职位建立
    • Here our job build successfully

      在这里,我们的工作成功建立

    The output of Jobs:

    Jobs的输出:

    Image for post
    • Here our jobs build successfully.

      在这里,我们的工作成功建立。
    • Name of jobs:

      工作名称:
    • $devjob.

      $ devjob。
    • $prod(Production)

      $ prod(生产)
    • $status.

      $状态。

    步骤8)运行管道作业 (Step-8) Run the Pipeline Job)

    • Now go and build the MYAL pipeline job.

      现在开始构建MYAL管道作业。
    Image for post
    build it
    建立它

    The output of the Pipeline:

    管道的输出:

    Image for post
    Pipeline console output
    管道控制台输出

    Jobdsl DSL Groovy代码说明:(Explanation of jobdsl DSL groovy Code:)

    在这里,我要进行三项工作,一项用于devjob,第二项用于生产,第三项用于部署状态检查。 (Here I am making three jobs one for devjobs, second for production, third for status checking of deployment.)

    devjob的解释: (Explanation of devjob:)

    当devjob由管道构建时,它的作用是,首先将其连接到AWS的节点。在那里,他们下载开发人员代码以准备docker iso,从GitHub链接提供的Dockerfile中为生产环境构建docker iso。 在建立之后,他们将推送到hub.docker.com进行拉取。 (When the devjob build by the pipeline, what it does, first it connect to the Node of AWS On there they download the Developer Code prepare the docker iso, build it docker iso for the production world from Dockerfile provided by the GitHub link. After that building, they push to the hub.docker.com for pulling.)

    devjob的输出: (Output of devjob:)

    Image for post
    AWS Ec2
    AWS Ec2
    • Here our code has been downloaded successfully.

      在这里,我们的代码已成功下载。
    Image for post
    docker image
    码头工人形象
    • Here our Docker image built successfully.

      在这里,我们的Docker镜像成功构建。
    Image for post
    • Here our ISO has been pushed into hub.docker.com

      在这里,我们的ISO已被推送到hub.docker.com

    产品说明: (Explanation of prod job:)

    devjob prod作业运行后,首先将其连接到适用于我的AWS EKS(弹性K8s群集)设置Linux节点,然后从GitHub代码下载群集代码,在群集中,它使用竞价型实例,并创建EKS群集通过使用eksctl命令,在此集群设置之后,它将为我们的生产创建一个部署,它将创建一个部署名称myweb,并使用由devjob构建的映像,并且还会对其进行缩放,并且在这里访问我的网站我正在使用服务使用AWS Loadbalancer的EKS中的LoadBalancer。 (After the devjob prod job runs, first it connect to Linux Node for my AWS EKS(Elastic K8s Cluster) setup, it downloads the cluster code from the GitHub code, In the cluster, it is using spot instance, and it creates the EKS cluster by using eksctl command, after this cluster setup, it creates a deployment for our production, it creates one deployment name myweb and uses an image which is built by the devjob, it also scales it, and Here for accessing my Website I am using service LoadBalancer in EKS, which is using AWS Loadbalancer.)

    产品作业的输出: (Output of prod job:)

    Image for post
    EKS cluster
    EKS集群
    • Here EKS cluster is ready.

      至此,EKS集群已准备就绪。
    Image for post
    clusters
    集群
    • Here our Nodegroup has been configured.

      此处,我们的节点组已配置。
    Image for post
    kubectl get deployments
    kubectl进行部署
    • Here U can see my all deployments running fine.

      在这里,您可以看到我的所有部署运行正常。
    Image for post
    LoadBalancer
    负载均衡器
    • AWS Loadbalancer created by the service of K8s, for accessing our Website.

      由K8s服务创建的AWS Loadbalancer,用于访问我们的网站。

    状态作业说明: (Explanation of status job:)

    这项工作继续进行,并检查该部署是否存在,如果没有,它将向相应团队发送电子邮件。 (this job goes and checks whether this deployment is there or not, if not it sends the email to the respective team.)

    状态作业的输出: (Output of status job:)

    Image for post
    • It is the test email send by Jenkins, it means our Jenkins E-mail job working fine.

      这是Jenkins发送的测试电子邮件,这意味着我们的Jenkins电子邮件工作正常。

    最终输出。 (FINAL Output.)

    • Copy Loadbalancer DNS name into the browser for website output.

      将Loadbalancer DNS名称复制到浏览器中以进行网站输出。
    Image for post
    Website
    网站
    • Here our Website comes, running on EKS cluster, using Loadbalancer.

      这是我们的网站,它使用Loadbalancer在EKS群集上运行。

    注意:为了监视这些节点组,我们可以使用由AWS提供的监视服务,但是不建议在这里使用Prometheus和Grafana作为指标,而Splunk为日志。 要了解更多,我们还可以设置警报。 (Note: For monitoring these Node Groups We can use monitoring services provided by the AWS, but it is not recommended here we can use Prometheus and Grafana for metrics, and Splunk for logs. for more, we can also set alarms.)

    Image for post
    Image for post
    Image for post

    最终解释: (Final Explanation:)

    Here I completed this project using END-TO-END Automation, for configuration management I use Ansible. My Devjob running on AWS EC2 using Jenkins multi Node Cluster, and my Production is running on one of the powerful services of AWS i,e AWS EKS provide the best resources, high availability, etc. and at last by status is checking whether my deployment is there or not, if not it sends the email to the teams.

    在这里,我使用END-TO-END Automation完成了这个项目,使用Ansible进行配置管理。 我的Devjob使用Jenkins多节点集群AWS EC2上运行,我的Production在AWS的一项强大服务上运行,即AWS EKS提供了最佳资源,高可用性等,最后按状态检查我的部署是否是否存在,如果没有,它将向团队发送电子邮件

    Github链接: (Github Link:)

    翻译自: https://medium.com/@rootritesh/devops-project-f17715ca132b

    devops 项目经理

    展开全文
  • DevOps 实践指南

    千次阅读 2018-11-06 11:54:33
    在此背景下,本书旨在提供从启动 DevOps 转型到实现目标所需的理论、原则和实践,帮助企业提高生产力、盈利能力并且赢得市场。本书不仅适用于从事或影响技术价值流中工作的所有人,通常包括产品管理、开发、QA、IT ...

    内容简介

    技术的有效管理对于商业竞争力而言空前重要。数十年来,技术领导者一直在努力平衡敏捷性、可靠性和安全性。在此背景下,本书旨在提供从启动 DevOps 转型到实现目标所需的理论、原则和实践,帮助企业提高生产力、盈利能力并且赢得市场。本书不仅适用于从事或影响技术价值流中工作的所有人,通常包括产品管理、开发、QA、IT 运维和信息安全,而且适用于业务和市场领导者。

    本书共分为6个部分:第一部分概述 DevOps 的历史和三个基本原则,即“三步工作法”;第二部分介绍开启 DevOps 转型的过程;第三到五部分深入探讨“三步工作法”的各个要素;第六部分关注如何将安全性和合规性正确集成到日常工作中。全书涵盖40余个 DevOps 案例,以谷歌、亚马逊、Facebook 等全球知名企业和组织的实际调查结果为依据,展示如何通过现代化的运维管理提升管理效率,进而为企业赢得更大市场、创造更多利润。

    作者简介

    Gene Kim,Tripwire 创始人、前 CTO,IT Revolution 创始人,DevOps 企业峰会主办人,畅销书《凤凰项目》合著者。

    Jez Humble,DevOps Research and Assessment 公司 CTO,加州大学伯克利分校信息学院讲师;曾任 ThoughtWorks 首席顾问。《精益企业》和 Jolt 大奖图书《持续交付》的合著者。

    Patrick Debois,DevOps 之父,致力于通过在开发、项目管理和系统管理之中应用敏捷技术来填补项目和运维之间的鸿沟。

    John Willis,Chain Bridge System 创始人,曾任 Docker 公司布道师,现就职于 SJ Technologies 公司。

    本书内容

    推荐语

    “以平台化、生态化、智能化和敏捷为主要特征的数字化时代已经到来,需要我们采用与之匹配的工作方法。DevOps 作为与数字化相适应的方法之一,其作用不可或缺。IT 人员要实现数字化转型,必须学会此方法,否则将难以胜任当前和未来的工作。”

    ——李长华,高德纳公司(Gartner)高级高管合伙人

    “经历了多年信息化实践,我深感打造坚强 IT 运维体系和能力对支撑企业经营管理的重要性。接触和深度了解 DevOps 之后,我最大的感受是,它有利于在改善传统‘稳态 IT’运维体系的过程中寻获到提升价值的诀窍,也是构建云计算时代‘敏态 IT’运维体系中不可或缺的柱石。”

    ——李红,中国中钢集团有限公司信息管理中心总经理

    “对很多人而言,DevOps 已经不是一个陌生的概念了,但是其思想精髓该如何融入传统企业的 IT 管理来助力企业提升商业竞争力呢?这仍然是 CIO 及其团队面临的挑战。本书结合48个著名公司的案例,介绍了高绩效公司是如何利用 DevOps‘三步工作法’原则取得成功的,相信一定会使读者受益匪浅。”

    ——李炜,中国卫通集团信息中心主任

    “在访谈了‘DevOps 之父’Patrick Debois 之后,我深刻地理解了‘DevOps is the Human Factor’这句话的真谛。DevOps 是不断演进的,不是能够被固化定义下来的标准化流程体系。DevOps 是一场关于工作方式的革命和企业文化的运动,同时也是企业数字化转型中高效团队所必备的能力。本书是继《凤凰项目》之后,Gene Kim 携手全球三位 DevOps 界大咖的扛鼎之作,无愧‘全球 DevOps 畅销书’的美誉。”

    ——孙振鹏,EXIN 国际信息科学考试学会亚太区总经理,DevOpsDays 中国发起人

    “过去的20年里,中国大型商业银行逐步构建了以研发、测试、运维团队为主体的 IT 组织架构,基于 ITIL 建立了信息系统建设和服务的流程。然而,金融科技浪潮的到来要求对产品进行迭代开发、敏捷测试、快速部署,必须同时满足业务连续性、服务稳定性与业务快速创新的要求。因此,IT 体系向 DevOps 转型成为了一个备受关注的课题。本书既是国际 DevOps Professional 认证的核心教材,也为 DevOps 转型提供了从启动到实现所必需的理论、原则和实践案例。”

    ——涂晓军,中国农业银行数据中心总经理

    “科技属性正在成为企业能否长期健康成长的核心要素,以个性化和最佳体验为核心的服务运营模式对业务快速创新迭代能力提出了极高的要求。DevOps 为技术组织提供了卓越的能力,来实现科技创新和业务发展的高效融合、协同和共赢。”

    ——徐斌,雪松控股集团 CIO,前壳牌中国 CIO

    “为保证交付质量,传统理论和做法是开发、测试、运维各自设定自己的目标和准入、准出规则,严控变更。IT 人员很累,业务部门却不买账。DevOps 开创了开发、运维一体化的理念、方法和流程。面对银行正在实施的数字化转型,本书的出版可谓恰逢其时。”

    ——王燕,中信银行信息技术管理部总经理

    (以上为中文版推荐语,按姓氏拼音排序)


     

    “这是一本切合实际、实用性强、具有指导意义的指南,能帮你完成《凤凰项目》中所有令人拍手叫绝的事情。”

    ——Tom Limoncelli,Stack Exchange 问答平台 SRE 经理,曾任谷歌公司 SRE/系统管理员

    “对于想理解、解释和实现 DevOps 文化、流程和工具,来达成高性能运维的任何人而言,本书都是不二之选。”

    ——Quentin Fennessy,埃森哲公司 DevOps 架构经理

    “我一直在找探讨如何在大型组织中实现 DevOps 的书,不得不说,本书‘一站式’地让我了解到了许多:不仅包括技术方面,而且包括业务方面。”

    ——Jumy Mathew,Sogeti 公司首席顾问,欧盟委员会应用架构师

    “本书对 DevOps 新手和老手来说都是很好的材料。作为《凤凰项目》小说的续作,它毫不逊色……强烈推荐。”

    ——Hamlet Khodaverdian,LMNTRIX 公司美洲区副总裁

    “这本书没有大肆宣扬 DevOps,而是公开承认 DevOps 是几种实践的结合,例如精益、ITSM、敏捷、约束理论等。本书探索了如何搭配使用它们。希望你读得愉快,并且加入这场运动。”

    ——Daniel Breston,Virtual Clarity 公司 DevOps 顾问

    (以上为原版推荐语)

    译者序

    在十几年的工作经历中,我见证了国内企业数据中心建设和发展的过程。大型企业的数据中心拥有几千台服务器和网络设备,拥有全套的监管控平台。当踱步于轰鸣的机架丛林里时,当与夜间奋战的变更团队一起凝视着命令执行出错的屏幕时,我们可以清晰地感受到 IT 运维组织里那种特有的恐惧感和紧张感。

    这一切是不是都应该去埋怨墙另一侧的开发团队呢?在平日里,应用系统是被圈养的宠物;而在发生事故的那一刹那,它就变身为一头难以驯服的猛兽。从 IT 组织整体来看,当前运维人员的痛是深刻而明显的!而开发人员同样是深受夜班出租车司机喜爱的人群。相对于运维团队而言,他们的精神世界和现实世界要更加美好一些。开发团队实施了很多年的敏捷软件开发,有着自己的关于完成的定义。即使你现在去翻阅一本最新出版的 Scrum 敏捷开发指南,翻到关于完成的定义的章节时,还是可以看到类似这样的定义:“冲刺的目标是要产生一个潜在可发布的产品增量,达到大家一致认可的完成程度。”我对这样的定义感到非常忧虑:它能意味着每个冲刺的开发结果可以正常地运行在类生产环境中吗?能意味着可以按照业务人员的需要马上开展小范围的真实用户实验吗?运维人员能否在系统濒临崩溃之前自行关闭这个功能?

    可以肯定的是,现在开发和运维还不能在统一的、为客户交付价值的目标下工作,他们像是生活在不同的星球上。这个问题并不是我国特有的。回顾一下从2009年开始的 DevOps 运动吧!这是一次能让开发和运维感到同样兴奋的技术实践变革,其中也充满了人文变迁。

    我在不停地思索,应该怎样破解以上困境。在研究 DevOps 相关技术实践一段时间之后,各种答案终于陆续浮现。我很幸运地接受了本书的翻译工作。对我来说,这是一次深度的 DevOps 学习研究之旅,组织几个好友共同经历这个过程也非常难得。现在可以确定的是,DevOps 的理论、原则和实践就一条“更好的道路”,就是我们需要的答案;它能让开发和运维深度地融合为同一支“球队”,使他们朝着“进球”这一共同目标协同努力,而不再是彼此对抗和怀疑。它将测试和信息安全工作一同融入了这个统一的框架当中,将保障质量和安全变为每个人日常工作的一部分。本书用 DevOps“三步工作法”的形式展示了所有相关细节。它适用于 IT 组织里所有的级别和角色,值得任何拥有改进想法的人深入学习。

    本书对开发和运维具有同样重要的意义,而且覆盖了传统的 QA 测试和信息安全工作;它是传统的敏捷开发、精益管理和 ITSM 管理等实践各自发展多年以后的首次 IT 管理实践大融合。本书和 DevOps 本身应该得到更广泛的应用和推广。本书的出版离不开翻译团队和图灵编辑团队的专业精神,以及双方的共同努力。在此我统一向所有合作者表示感谢。

    此外,谨以此书献给我的妻子丽娜和女儿禹含,感谢她们在这13个月时光里的支持。特别让我欣慰的是,女儿不仅明白什么是图书翻译,而且在网络英语课上有很棒的表现,也感谢她能容忍我因此而减少了与她陪伴和玩耍的时间。

    刘征

    2018年2月14日(丁酉年腊月二十九)


     

    2016年9月的一个周末,当时我正在参加 EXIN 举办的 DevOps Master Trainer 的培训,刘征向我推荐了这本书,并邀请我共同完成中文版的翻译工作。出于对 Gene Kim 的《凤凰项目》一书的喜爱,对能够参与本书的翻译工作,我非常期待。

    一周后,当我第一次阅读本书的预览章节时,顿时被其中的内容所吸引。本书不仅将敏捷、精益和持续交付等理念的诠释上升到一个新的高度,而且剖析了在这个安全漏洞频发、交付周期不断缩短、技术大规模转型的时代,当技术领导者们面对安全性、可靠性和灵活性等诸多挑战时,为什么 DevOps 能够脱颖而出——它帮助组织缩短价值交付流程,打造高可靠性、高安全性的产品,并提高了企业竞争力和员工满意度。

    本书从业务视角描述了 DevOps 的必要性,分析了为什么 DevOps 是基于精益、约束理论、丰田生产系统、学习型组织、康威定律等知识体系的集大成者。同时,它系统性地定义了 DevOps“三步工作法”:流动原则、反馈原则、持续学习与实验原则,并阐述了 DevOps 实施需遵守的原则与最佳实践。

    • 流动原则:它加速了从开发、运维到交付给客户的正向流程。
    • 反馈原则:它使组织构建安全、可靠的工作体系,并获得反馈。
    • 持续学习与实验原则:它打造出一种高度信任的文化,并将改进和创新融入日常工作中。

    DevOps 对技术行业带来的变化,就如同精益在20世纪80年代对制造业的变革一样。那些拥抱 DevOps 的组织将构建出充满激情、持续进步的学习型组织,并能通过创新的方式表现得比竞争对手更加出色。在本书中,作者引入了大量的业界成功案例,包括谷歌、Etsy、塔吉特、LinkedIn 等一流的互联网公司,描述了他们在 DevOps 转型过程中面临的挑战以及应对方式,指引读者站在巨人的肩膀上思考。

    DevOps 使价值流里的所有参与者都受益匪浅。无论你是开发人员、运维工程师、质量保证工程师、信息安全人员还是产品经理,它都能够带来开发伟大产品而产生的快感。它能使团队共同成长并持续获益。相信读过本书之后,你一定会产生强烈的共鸣。

    感谢我的妻子晓丽和儿子锦熙,翻译本书占用了我大量业余时间,没有你们的支持,我不可能完成这项工作。感谢本书的其他几位译者——刘征、马博文、曾朝京,和你们的合作让我获益良多,也感谢图灵负责本书审校工作的编辑们,你们逐字逐句的检查、校对和修改提高了译文的质量,谢谢你们!

    最后,祝读者们享受 DevOps 的实践之旅!

    王磊

    2018年2月20日


     

    2011~2017年,我一直在为 ThoughtWorks 的一个海外交付项目工作。我们和客户一起,从持续集成、两周一次部署,做到了持续交付、随时部署,同时应用架构微服务化,也实现了上云以及容器化部署。

    在这个过程当中,我们切实地采用和执行了业界的良好技术和工程实践,如微服务、蓝绿部署、不可变部署、基础设施即代码等。我也曾经阅读和翻译过 DevOps 的相关图书,但总觉得还是和我们的实践有点差距。

    在这段时间中,我的角色也从开发者变为 DevOps(我个人不太喜欢这个称呼,因为我认为 DevOps 更多的是实践而不是角色)。同时,我组织了西安 DevOpsMeetup 的活动,期望能通过社区分享更多关于 DevOps 的知识。每次活动时,总是有朋友问如何实现 DevOps,我却发现即便亲身经历了这个过程,也无法给出更高层面的回答,而且也没有在别的文章和书籍中找到答案。

    很幸运,因为社区活动而结识的刘征向我发出了翻译本书的邀请。在翻译的过程当中,我找到了如何系统性实现 DevOps 的答案。通过“三步工作法”铺平流程,选择合适的切入点,根据康威定律调整组织、持续交付、自动化、运维改善等。对于尚未实现 DevOps 的 IT 组织来说,这是一本不可多得的指南。

    翻译本书,收获颇多。本书的作者 Patrick、Gene、Jez 和 John 确实贡献了一本集 DevOps 大成的著作。希望读者在阅读后也会有相同的感受,能够在团队中逐渐采用本书提供的工作法或者实践,改进交付速度、质量、软件可用性以及构建高可扩展的组织结构。

    翻译是一件费时费力的工作。感谢我的妻子王嘉,能包容我放弃陪她的时间来完成这一项工作。感谢一起合作的几位译者——刘征、王磊、曾朝京,和你们一起合作非常愉快。感谢 Trent、Cos 等 REA 的朋友,是你们带我走上了 DevOps 之路。最后,祝各位读者在阅读完本书后,都能找到实践 DevOps 的方法,并且行动起来,开启 DevOps 的探险之旅并持续从中受益。

    马博文

    2018年3月4日


     

    2012年,我第一次在公司的年度全球会议上接触到 Dev+Ops 的概念。那时候,IT 服务管理的理念在国内 IT 运维领域已经深入人心,保障生产系统的可靠性和安全性仅仅是运维工作的基本内容,许多企业的 IT 部门越来越关注对业务部门需求的反应速度和给业务带来的实际成效,要求进一步提高 IT 服务的工作效率和工作质量。显然,要提高 IT 服务的整体绩效,不能仅仅局限于运维工作的范畴,也不是 ITIL 最佳实践就能够解决的问题。越来越多的 IT 人员都有相同的困惑,我也在一直思考:还有什么更好的方法能提高 IT 绩效?!

    Dev+Ops 提出将开发和运维团队的工作紧密结合起来,建立持续交付和持续反馈闭环,这个思路让人耳目一新。但是彼时 DevOps 还在实践中探索,各种阐述 DevOps 的文章还是比较片面的,甚至有一些见解是相悖的。关于如何开展 DevOps,应该做什么、如何做,业内一直缺乏形成体系的说明。

    随着 DevOps 的概念越来越受到关注,我对开展 DevOps 的困惑也越来越多。当我看到本书英文版时,虽然只有一个样章,但是它已经能让我确信,关于如何开展 DevOps 的很多问题都会在其中找到答案。于是,我欣然接受刘征的邀请,参与了本书的翻译工作。

    翻译本书的过程就是学习和思考 DevOps 实践方法的过程。在这个过程中,我经常会经历作者在文中描述的“啊哈”时刻:疑惑解决了,思路豁然开朗。我相信本书的每一位读者都会经历这样的顿悟时刻。

    在这本书的翻译过程中,翻译团队也实践了“三步工作法”中的第二步——反馈原则。反馈原则的核心思想是:虽然复杂的系统不可避免地存在错误,但是可以通过采取安全措施确保在质量问题出现之前,快速发现和处理错误。4个译者在分别翻译了不同的章节之后,都发现了在初稿中有诸多对原文理解的分歧和名词翻译不统一的问题。大家商议后决定,遵照“三步工作法”的反馈原则,全组集中从第一个章节开始交叉审阅、按序检查;发现问题及时在小组范围内讨论;形成一致意见后,分别回到自己负责的章节中修改。这个过程正是在 PDCA 中识别问题、群策群力解决问题、构建新知识并将局部知识应用到全局的过程。在这个过程中,每一个人也对 DevOps 实践有了更深刻的认识。

    本书用大量真实的案例描述了 DevOps 实践产生的过程。他们所遇到的问题和困境,很多 IT 团队都曾经经历、正在经历,甚至在未来不可避免地即将经历。希望本书能在你感到困惑之时,对你有所启发、有所帮助。

    经过13个月,本书终于出版在即了。翻译工作占用了我大量的业余时间,感谢我的父亲、母亲、丈夫和儿子,他们让我在翻译文章的那些夜晚和周末,只做一个繁忙的影子。

    感谢一起翻译此书的伙伴们——刘征、王磊和马博文,以及图灵公司的编辑们。

    曾朝京

    2018年3月3日


     

    特别感谢 EXIN 国际信息科学考试学会为本书提供的 DevOps Professional 认证考试样题及解析。《DevOps 实践指南》是 EXIN 国际信息科学考试学会指定的 DevOps Professional 国际认证核心教材。

    序言

    许多工程领域在过去都经历了长足的发展,它们不断地“提高”对本学科的认知和理解。虽然土木、机械、电气、核能等工程领域都有对应的大学课程和专业机构,但事实上,现代社会需要的是各种形态的工程学科相互交叉影响并从中受益。

    想一想高性能车辆的设计工作。机械工程师的工作是在哪个环节结束的?电气工程师的工作是从哪个环节开始的?拥有空气动力学领域知识的人(对车窗的形状、大小和位置有很好的发言权)在哪儿(如何以及何时)开始和人体工程学专家协作?在车辆整个使用寿命期间,燃料混合物和汽油对发动机和变速器材料有什么化学影响?针对汽车设计,我们还能提出很多其他方面的问题,但最终的结论是一样的:要想在现代技术上取得成功,必然需要多方向和多专业领域的协作。

    任何一个领域或学科想要取得进步和成熟,就需要认真反思它的起源,在反思中寻求不同的观点,并把这些不同观点的来龙去脉思考清楚,这对预见未来发展是非常有帮助的。

    本书代表了这样一种承前启后的观点,它应该被视为软件工程和运维领域(在我看来,它仍在发展和快速地演变)里一个具有开创性的观点。

    无论你处在哪个行业,无论你的公司提供什么产品或服务,这种思维方式对于所有业务和技术领导者都是至关重要且必不可少的,因为它关乎着企业的存亡。

    John Allspaw

    Etsy 首席技术官

    2016年8月于纽约布鲁克林

    前言

    啊哈!

    本书的写作由来已久。早在2011年2月,我们几位合著者就开始每周一次的 Skype 通话,准备写一本通用的 DevOps 参考指南,算作《凤凰项目:一个 IT 运维的传奇故事》[1]的姊妹篇。

    前后历时5年多,耗费2000多小时,本书终于呈现在你的面前。过程相当漫长,但也是一个非常有益且难得的学习过程,最终涉及的范围比我们早期预想的更广。在整个写作过程中,所有合著者都始终坚信 DevOps 的重要性。我们在早期的职业生涯中,都曾经历过“啊哈”的顿悟时刻,相信很多读者也都会与我们产生共鸣。

    Gene Kim

    从1999年以来,我有幸一直在研究高绩效技术组织,最早的一个发现是:IT 运维、信息安全和开发等不同职能部门之间的良好合作是成功的关键。我依然清楚地记得第一次看到由于这些部门目标相左导致恶性循环的场景。

    那是在2006年,我跟某管理团队待了整整一星期,他们当时正在为一家大的机票预订公司提供外包 IT 运维的管理服务。他们给我描述了每年要做的软件升级的后果:每次发布都会让外包商和客户的服务中断;由于客户受到了影响,公司也会根据服务等级协议(SLA)受到处罚;公司利润下滑,不得不解雇一些很有才华和经验的员工;由于有大量计划外的工作和紧急任务,剩下的员工无法处理日益增长的客户服务请求;只好投入中层管理团队一道完成合同要求;所有人都认为3年后肯定得重新招标。

    这种绝望和无助的感受使我加入了这场道义上的征程。开发似乎总是被视为战略性的,而 IT 运维则被视为战术性的,因此常常被委托甚至整个外包出去,结果是5年后的情形比当初交接时更加糟糕。

    多年来,我们许多人都认为一定有更好的做法。在2009年的 Velocity 会议上,我看到了这样的演讲——介绍了在架构、技术实践和文化方面并举的革新(我们现在称之为 DevOps)所产生的惊人效果。当时,我非常兴奋,因为它就是我们一直在寻找的那个更好的方法。传播 DevOps 是我合著《凤凰项目》的动机之一。你可以想象,看到更广大的社群对那本书做出的反应,说它是如何帮助他们实现自己的“啊哈”时刻的,我是多么地倍感欣慰!


    Jez Humble

    我的 DevOps“啊哈”时刻发生在2000年,当时我就职于一家创业公司,那是我毕业后的第一份工作。有一段时间,我是公司仅有的两名技术人员之一。我包揽了网络、编程、支持、系统管理等一切工作。我们通过 FTP 直接从工作站往生产环境部署软件。

    我在2004年加入了 ThoughtWorks 咨询公司,参与的第一个项目涉及大约70人。我所在的部署团队共8名工程师,团队的主要工作就是将软件部署到类生产环境中。刚开始的时候,工作非常紧张。但几个月后,我们就从需要花两个星期的手动部署,进步到了只用一个小时的自动化部署。在正常的工作时间段里,我们也可以使用蓝绿部署模式,以毫秒为单位来发布或者回滚业务的应用。

    这个项目对《持续交付:发布可靠软件的系统方法》[2]和本书的诸多想法都很有启发意义。对于我和从事该领域工作的其他人而言,动力有两个:我们知道无论是什么限制,总能做得更好;我们热切希望帮助那些正在奋斗的人们。


    Patrick Debois

    对我来说,DevOps 意味着一系列的回忆。2007年,我与几个敏捷团队一起,做一个数据中心迁移项目。我很嫉妒他们的高生产力——能够在很短的时间里做很多的工作。

    在接下来的一个项目中,我便开始在运维工作中试验看板方法(Kanban),并看到了团队的显著变化。后来,在2008年的多伦多敏捷大会上,我基于这个实践发表了一篇 IEEE 论文,不过当时它并没有在敏捷社区里引起广泛的共鸣。我们创建了敏捷系统管理组(Google Group),但忽视了人这一因素。

    在2009年的 Velocity 会议上,我听了 John Allspaw 和 Paul Hammond 所分享的“每日10次部署”的演讲以后,确信其他人与我英雄所见略同。因此我决定组织第一次 DevOpsDays 活动,误打误撞地创造了“DevOps”这个词。

    DevOpsDays 活动体现了独特的魅力和感染力。当人们开始因 DevOps 改善了他们的工作而感谢我时,我才真正意识到它的影响力。从那以后,我就开始持续地推广 DevOps。


    John Willis

    2008年,我第一次见到 Luke Kanies(Puppet Labs 的创始人)本人,那时我刚刚出售了专注于大型系统的配置管理和监控(Tivoli)实践的咨询业务。Luke 在 O'Reilly 开源大会的配置管理分会场里介绍了 Puppet 软件。

    演讲刚开始时,我在会场最后一排走来走去消磨时间,心想:“关于配置管理,这个20岁的年轻人能讲些什么呢?”毕竟,我在整个职业生涯中,基本都在帮助世界上最大的那些企业构建配置管理和其他运维管理方案。然而,他大约讲了5分钟后,我就坐到了第一排,同时意识到在过去20年里,我真是一无是处。Luke 所描述的就是现在我们所说的第二代配置管理。

    在他演讲完之后,我找机会和他坐下来一起喝了杯咖啡。我完全被“基础设施即代码”(infrastructure as code)的理念所折服了。Luke 一边喝着咖啡,一边更详细地向我阐述了他的想法。他告诉我,他相信运维人员的工作模式可能会变得像开发人员一样,他们必须在源代码控制系统里维护系统的配置,并在工作中使用持续集成/持续交付(CI/CD)的模式。作为一名 IT 运维的老兵,我当时的回应大概是“运维人员不会喜欢你这个想法的”。(显然是我错了。)[3]

    大约又过了一年,在2009年 O'Reilly 的 Velocity 会议上,我听了 Andrew Clay Shafer 关于敏捷基础设施的演讲。在演讲中,Andrew 展示了一幅形象的插图,图中的开发部门和运维部门之间存在一堵高墙,以此隐喻工作被两个部门踢来踢去。他将此称为“混乱之墙”(the wall of confusion)。这个想法其实和一年前 Luke 的想法如出一辙,这让我眼前一亮。那年年底,我作为唯一受邀的美国人,参加了比利时根特市的首次 DevOpsDays 活动。在活动结束时,这个所谓 DevOps 的东西已然融入了我的血液。

    显然,本书的合著者都有类似的顿悟,尽管他们来自完全不同的方向。有充分的证据表明,上述这些问题几乎在所有地方都发生过,而那些 DevOps 相关的解决方案也几乎是普遍适用的。

    编写本书的目的是描述如何复制我们参与过的或观察到的 DevOps 转型的成功经验,驳斥那些说 DevOps 在某些场景里行不通的谬论。以下是我们听说过的关于 DevOps 的一些最常见的误区。

    误区1:DevOps 只适用于创业公司。虽然谷歌、亚马逊、Netflix 和 Etsy 等互联网“独角兽”公司是 DevOps 的先行者,但这些公司在过去都面临过巨大的风险,而且他们所遇到的问题和传统企业相比并无二致:软件的高风险代码容易导致灾难性故障,无法快速发布新功能来击败竞争对手,存在安全合规性问题,服务无法扩容,开发和运维彼此高度不信任等。

    然而,这些公司都能够适时地改变它们的架构、技术实践和文化,如今他们都创造出了惊人的 DevOps 成果。正如信息安全高管 Branden Williams 博士所说:“不要管 DevOps 是适合独角兽还是马,只要跑得快就能抵达目的地。”

    误区2:DevOps 将取代敏捷。DevOps 的原则和实践与敏捷方法一致,许多人认为 DevOps 是自2001年开始的敏捷之旅的合理延续。敏捷通常是 DevOps 效率的保障,因为它专注于让小团队向客户持续交付高品质的代码。

    如果我们每次迭代的目标不限于“潜在可交付的代码”,而是扩展到让代码始终处于可发布状态,让开发人员每天都把代码提交到主干,并在类生产环境中做功能演示,那么许多 DevOps 相关的实践就会浮现。

    误区3:DevOps 与 ITIL 不兼容。许多人认为,DevOps 与1989年发布的 ITIL(Information Technology Infrastructure Library,IT 基础架构库)或 ITSM(IT Service Management,IT 服务管理)是背道而驰的。ITIL 广泛影响了好几代运维实践者,包括本书的一位合著者,并且它依然在演进,是一个不断发展的实践体系,旨在稳定地支撑世界级的IT运维,而且横跨服务战略、设计和支持等流程和实践。

    DevOps 实践可以与 ITIL 流程兼容。然而,为了支持 DevOps 所追求的更短的发布周期和更频繁的部署,ITIL 流程的许多方面需要完全自动化,以解决配置和发布管理流程相关的许多问题,例如保持配置管理数据库和最终软件库是最新的。由于 DevOps 需要在服务事件发生时进行快速的定位和恢复,因此这些其实还是和 ITIL 的服务设计、事件和问题管理方面的原则相一致。

    误区4:DevOps 与信息安全及合规活动不兼容。传统控制手段(例如职责分离、变更审批流程、项目结束时的手动安全审查)的缺位,可能会令信息安全和合规审计人员感到失望。

    然而,这并不意味着采用 DevOps 的公司里没有有效的控制,只是它并不一定体现在项目结束时的安全和合规性活动中,而是集成到了软件开发生命周期的每一项日常工作中,因此会得到更好的质量、安全性和合规性。

    误区5:DevOps 意味着消除IT运维,即“NoOps”。许多人错误地将 DevOps 解释为完全消除 IT 运维的职能,然而,这种情况是很少见的。虽然 IT 运维工作的性质可能会发生改变,但它仍然像以前一样重要。IT 运维团队要在软件生命周期的早期就与开发团队开展合作。在代码部署到生产环境中后,开发团队也要继续与运维团队合作。

    IT 运维不只是工单驱动的手动操作,而是能够通过自助服务平台和 API 来提升开发人员的生产效率,让他们能自助地创建开发环境、测试和部署代码、监控和显示业务运行的状态等。通过这种方式,IT 运维人员变得更像是开发人员(或者 QA 和信息安全人员),融入到了产品开发过程中,而该产品则是开发人员在生产中用来安全快速地测试、部署和运行 IT 服务的平台。

    误区6:DevOps 只是“基础设施即代码”或自动化。尽管本书所展示的许多 DevOps 模式都需要自动化,但是 DevOps 还需要文化规范和架构,以便在 IT 价值流中实现共同的目标。而这远远超越了自动化的范畴。DevOps 最早的拥护者之一Christopher Little 也是一名技术主管,他写道:“DevOps 不仅是自动化,就像天文学不只是望远镜一样。”

    误区7:DevOps 仅适用于开源软件。尽管许多 DevOps 成功案例发生在使用 LAMP 栈(Linux、Apache、MySQL、PHP)等构建软件的公司,但实现 DevOps 与所使用的技术无关。在使用 Microsoft .NET、COBOL 和大型机汇编语言以及 SAP 甚至嵌入式系统(如惠普 LaserJet 打印机固件程序)等编写应用程序的公司,DevOps 也能取得成功。

    传播“啊哈”时刻

    本书的每一位作者都被 DevOps 社区里发生的惊人创新及成果深深地打动和启发:他们正在创建安全的工作系统,让小型团队能够快速独立地开发和验证能够为客户安全地部署的代码。我们相信,DevOps 是创建动态、学习型且强化高度信任的文化规范的公司的一种表现形式,这些公司一定会持续地在市场上创新并在竞争中脱颖而出。

    我们真诚地希望本书能以多种方式为许多人提供价值,它可以是一个 DevOps 转型计划和实践指南,也可以是一组可供研究和学习的参考案例,可以是一部 DevOps 编年史,也可以是一种联结产品经理、架构师、开发人员、QA、IT 运维和信息安全团队以实现共同目标的方法,可以是一条为 DevOps 活动获取高层领导支持的途径,也可以是一种改变技术组织管理方式的道德使命,以帮助企业提高效率,创造更快乐和更人性化的工作环境,并帮助每个人成为终身学习者。这不但能帮助每个人实现他们个人的最高目标,而且还能帮助他们的公司取得更大的成功。


    [1] 关于《凤凰项目》,详见http://www.ituring.com.cn/book/1545。——编者注

    [2] 关于《持续交付》,详见http://www.ituring.com.cn/book/758。——编者注

    [3] 此处引用了关于 Led Zeppelin 抄袭的八卦。——译者注

    第一部分 DevOps 介绍

    在本书的第一部分中,我们将回顾在管理和技术领域里所发生的几个重大事件,了解它们是怎样为 DevOps 的诞生奠定了基础的。同时,我们还将介绍“价值流”这个概念,解释为什么 DevOps 是把精益原则应用到技术价值流中的结果,并探讨 DevOps 的三步工作法:流动、反馈以及持续学习与实验。

    第一部分包括以下内容。

    • 流动原则:它加速了从开发、运维到交付给客户的流程。
    • 反馈原则:它使我们能建设出更安全可靠的工作体系。
    • 持续学习与实验原则:它打造出一种高度信任的文化和一种科学的工作方式,并将对组织的改进和创新作为日常工作的一部分。

    简史

    DevOps 和它所产生的技术、架构及文化实践,体现了哲学和管理学原则的融合。虽说这些原则是由不同组织独立发现的,但 DevOps 博采众长,形成了 John Willis(本书作者之一)所说的“DevOps 的大融合”,展现了人们思想上的惊人进步和不可思议的相互关联。基于制造业实践了数十年的管理经验,它是将可靠性组织、信任度管理与 DevOps 实践相结合的产物。

    DevOps 基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系,并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到 IT 价值流中,就产生出 DevOps 这样的成果。将它贯彻于整个技术价值流中,涉及产品管理、开发、QA、IT 运维和信息安全专员等不同角色,在更低的成本和努力下,保障产品的高质量、可靠性、稳定性和安全性。

    虽然 DevOps 是精益原则、约束理论和丰田套路运动的衍生物,但也被许多人视为始于 2001 年的敏捷运动的延续。

    精益运动

    价值流映射、看板和全面生产维护这些实践起源于 20世纪80年代的丰田生产系统。1997年,精益企业协会开始研究如何将精益理念应用于服务业和医疗行业等其他价值流中。

    精益的两个主要原则包括:坚信前置时间(把原材料转换为成品所需的时间)是提升质量、客户满意度和员工幸福感的最佳度量指标之一;小批量任务的交付是缩短前置时间的一个关键因素。

    精益原则聚焦在如何通过系统性思考为客户创造价值,系统性思考的范围涉及建立持久目标,拥抱科学思维,创造流和拉动(而非推送)的协作模式,提倡从源头保证质量,以谦逊为导向,尊重流程中的所有个体。

    敏捷宣言

    敏捷宣言是在2001年由软件领域的17位顶尖大师共同提出的。他们希望用一套轻量级的价值观和原则体系,来优化那些沉重的软件开发流程(如传统的瀑布式开发模型)和方法论(如统一软件开发过程)。

    在敏捷宣言中,一个重要的原则是“频繁地交付可工作的软件,交付周期可以是数星期也可以是数月,推荐更短的周期”,并强调使用小批量任务进行增量发布,而非大规模的作业和瀑布流程的发布。同时,强调建立自组织的小团队,让成员在高度信任的环境中愉悦地工作。

    在很多实施了敏捷的企业里,生产效率显著提升,敏捷也因此获得了越来越广泛的支持和认可。有趣的是,在 DevOps 的发展历程中,如下所述的几个关键活动都发源于敏捷社区或者敏捷大会。

    敏捷基础设施和 Velocity 大会

    在2008年加拿大多伦多的敏捷大会上,Patrick Debois 和 Andrew Clay Schafer 主持了一场研讨,提倡将敏捷原则应用到基础设施而不是应用程序的代码上。尽管研讨的参与者数量并没有达到预期,但是他们还是很幸运地找到了几个志同道合者,其中包括本书作者之一 John Willis。

    在2009年的 Velocity 大会上,John Allspaw 和 Paul Hammond 分享了题为“每日10次部署:Dev 和 Ops 在 Flickr 的协作”的演讲,讲述了他们如何建立 Dev 和 Ops 共享的目标,并通过运用持续集成等实践,将部署变成了日常工作的一部分。据当时在场的听众回忆道,所有的参与者都认为他们见证了这个具有深远意义的历史性时刻。

    虽然 Patrick Debois 并不在现场,但他对 Allspaw 和 Hammond 的想法产生了浓厚的兴趣,并在2009年比利时的根特市(他的居住地)发起了第一次 DevOpsDays 活动。“DevOps”这个术语也应运而生。

    持续交付

    基于持续构建、测试和集成的开发原则,Jez Humble 和 David Farley 进行了延伸,提出了持续交付,并首次在2006年的敏捷大会上做了分享。在持续交付中,“部署流水线”确保代码和基础设施始终处于可部署状态,所有提交到主干的代码都可以安全地部署到生产环境。2009年, Tim Fitz 在博客上发表了一篇题为“持续部署”的文章。[1]

    丰田套路

    Mike Rother 在2009年编写了《丰田套路:转变我们对领导力与管理的认知》一书,书中融入了他在丰田产品系统(TPS)中所积累的20年实践经验。他也曾参与了精益工具箱的制作。 Mike 在读研究生期间,曾和通用汽车公司的高层一起去日本参观丰田工厂,有一件事让他感到困惑:所有应用精益原则的公司中,没有一家能达到丰田的水平。

    之后,Mike 得出了结论:精益社区中大多数企业都没有抓住精益的核心——改善套路(Kata)。他解释说,所有企业都有日常的工作流程,而这些日常工作决定了最终的产出。通过设定目标,制订每周的详细计划,并持续改善日常工作,如此循序渐进,才能达到优化和改进的目的。

    以上描述了 DevOps 的发展历史和大事记。在接下来的内容里,我们将主要介绍价值流,以及如何将精益原则应用到技术价值流中;同时介绍三步工作法:流动、反馈和持续学习与实验。


    [1] 另外,DevOps 还基于并拓展了“基础设施即代码”的实践,该实践由 Mark Burgess 博士、Luke Kanies 和 Adam Jacob 共同提出。在“基础设施即代码”这种实践中,运维工作被最大程度地自动化,并确保任何对基础设施的操作都通过代码来实现,从而将现代软件的开发实践应用到了整个产品交付中,其特性包括持续集成(由 Grady Booch 提出,是极限编程的12个实践之一)、持续交付(由 Jez Humble 和 David Farley 提出)和持续部署(由 Etsy、Wealthfront 和 Eric Ries 在 IMVU 的工作中提出)。

    第1章 敏捷、持续交付和三步法

    本章将阐释精益制造的基础理论和三步工作法原则,从后者能衍生出各种 DevOps 行为。

    我们侧重于这些理论和原则,它们记录了制造业、高可靠性企业、高信任管理模型等几十年的经验,DevOps 实践正是基于这些经验衍生而来的。具体的原则和模式及其在技术价值流中的应用,会在本书的后续章节中陆续呈现。

    1.1 制造业价值流

    精益中的一个基本概念叫价值流。我们先在制造业的场景中定义它,再讨论如何将它应用到 DevOps 和技术价值流中。

    Karen Martin 和 Mike Osterling 曾在 Value Stream Mapping 一书中把价值流定义为“一个组织基于客户的需求所执行的一系列有序的交付活动”,或者是“为了给客户设计、生产和提供产品或服务所需从事的一系列活动,它包含了信息流和物料流的双重价值”。

    在制造业的流程中,价值流随处可见,它始于接收到客户订单并将原材料发往工厂。为了缩短和预测价值流中的前置时间,通常需要持续地关注如何建立一套流畅的工作流程,包括减小批量尺寸、减少在制品(Work in Process,WIP)数量、避免返工等,同时还需要确保不会将次品传递到下游的工作中心,并持续不断地基于全局目标来优化整个系统。

    1.2 技术价值流

    在制造业中加速物理产品加工流程的原则和模式,同样可以应用到技术工作(及所有知识工作)中。在 DevOps 中,我们通常将技术价值流定义为“把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”。

    流程的输入是既定的业务目标、概念、创意和假设,始于研发部门接受工作,并将它添加到待完成工作列表中。

    接受了工作之后,研发团队将运用敏捷或迭代的开发流程,将那些想法转化为用户故事以及某种功能性说明,然后通过编写程序代码实现,再将代码签入到版本控制库中,接下来每次变更都将集成到软件系统并进行整体测试。

    应用程序或服务只有在生产环境中按预期正常地运行,并为客户提供服务,所有的工作才产生价值。所以,我们不但要快速地交付,同时还要保证部署工作不会产生混乱和破坏,如中断客户服务、性能下降或者信息安全不合规等问题。

    1.2.1 聚焦于部署前置时间

    部署的前置时间是价值流的一个子集,也是本书讨论的重点。价值流始于工程师[1](包括开发、QA、IT 运维和信息安全人员)向版本控制系统中提交了一个变更,止于变更成功地在生产环境中运行,为客户提供价值,并生成有效的反馈和监控信息。

    在第一个阶段中,工作主要包括设计和开发,它和精益产品开发有很多相似之处:都具有高度的变化性和不确定性,不仅需要创意,某些工作还可能无法重来,这导致无法确定总体处理时间。在第二个阶段中,工作主要包括测试和运维,它类似于精益制造。相比前一个阶段,它需要创造性和专业技能,力求可预见性和自动化,将可变性降到最低(如短的和可预测的前置时间,接近零缺陷),并满足业务目标。

    我们并不提倡在设计、开发中串行地完成了大批量的工作后,再转入测试、运维阶段(如使用大批量、基于瀑布模型的开发流程,工作在长生命周期的特性分支上)。恰恰相反,我们的目标是采用测试和运维与设计和开发同步的模式,从而产生更快的价值流和更高的质量。只有当工作任务是小批量的,并将质量内建到价值流的每个部分时,这种同步的模式才能实现。[2]

    1. 定义前置时间和处理时间

      在精益社区里,前置时间与处理时间(有时候也被称为接触时间或者任务时间)[3]是度量价值流性能的两个常用指标。

      前置时间在工单创建后开始计时,到工作完成时结束;处理时间则从实际开始处理这个工作时才开始计时,它不包含这个工作在队列中排队等待的时间(见图1-1)。

      {90%}

      图1-1 部署工作的前置时间和处理时间

      因为前置时间是客户能够体验到的时间,所以我们把重点放在缩短前置时间而不是处理时间上。不过,处理时间与前置时间的比率是十分重要的效率指标,为了实现快速的流动并缩短前置时间,必须缩短工作在队列中的等待时间。

    2. 常见的场景:为期数月的部署前置时间

      通常,部署前置时间动辄需要好几个月。在大型、复杂的企业里,使用着紧耦合的单体应用,少有集成测试的环境,测试和生产环境的前置时间很长,并且严重依赖于手动测试,或者需要各种审批流程,情况更是如此。这种情形下的价值流看起来如图1-2所示。

      {98%}

      图1-2 某部署前置时间为期三个多月的技术价值流

      (来源:2015年 Damon Edwards 的“DevOps Kaizen”)

      部署前置时间一旦变长,那么在价值流的每个阶段,几乎都需要“填坑”能手来补救。通常,很可能是在项目结束前,将开发团队的变更合并到一起后,才发现整个系统根本无法正常工作,有时甚至会出现代码都无法通过编译和测试的情况。每一个问题可能都需要几天甚至几周的时间来定位和修复,因此导致了极其糟糕的客户体验。

    3. 我们的目标:分钟级别的部署前置时间

      在 DevOps 的理想情况下,开发人员能快速、持续地获得工作反馈,能快速和独立地开发、集成和验证代码,并能将代码部署到生产环境中(自己部署或者他人部署)。

      我们可以通过如下方式达到这个目标:向版本控制系统中持续不断地提交小批量的代码变更,并对代码做自动化测试和探索测试,然后再将它部署到生产环境中。这样,我们就能对代码变更在生产环境中的成功运行保持高度自信,同时还能快速地发现并修复可能出现的问题。

      为了更容易地实现上述目标,还需要通过模块化、高内聚、低耦合的方式优化架构设计,帮助小型团队自治地工作。这样即便失败了,也能在可控范围内,而不至于对全局产生影响。

      通过上述方式,能有效地将前置时间缩短至分钟级别;即便在最坏的情况下,也不会超过小时级别。其价值流图如图1-3所示。

      {95%}

      图1-3 前置时间为分钟级别的技术价值流

    1.2.2 关注返工指标——%C/A

    除了前置时间和处理时间外,技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比(%C/A)。该指标反映了价值流中的每个步骤的输出质量。Karen Martin 和 Mike Osterling 描述道:“要获取%C/A,可以询问下游客户他们有百分之多少的时间收到了‘真正有用的工作’,即他们可以专心做有用的工作,而不必修复错误信息、补充信息,或者澄清那些本该确定的信息。”

    1.3 三步工作法:DevOps 的基础原则

    《凤凰项目》把三步工作法作为基础的原则,并由此衍生出了 DevOps 的行为和模式(见图1-4)。

    {70%}

    图1-4 三步工作法

    (来源:Gene Kim 在 IT Revolution Press 博客上发布的“三步工作法:DevOps 的基础原则”,访问于2016年8月9日,http://itrevolution.com/the-three-ways-principles-underpinning-devops/

    第一步,实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流,需要将工作可视化,减小每批次大小和等待间隔,通过内建质量杜绝向下游传递缺陷,并持续地优化全局目标。

    通过加快技术价值流的流速,缩短满足内部或者外部客户需求所需的前置时间,尤其是缩短代码部署到生产环境所需的时间,可以有效地提高工作质量和产量,并使企业具有更强的外部竞争力。

    相关的实践包括持续构建、集成、测试和部署,按需进行环境搭建,限制在制品数量,构建能够安全地实施变更的系统和组织。

    第二步,在从右向左的每个阶段中,应用持续、快速的工作反馈机制。该方法通过放大反馈环防止问题复发,并能缩短问题检测周期,实现快速修复。通过这种方式,我们能从源头控制质量,并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统,还可以在灾难性事故发生前就检测到并解决它。

    及时发现并控制这些问题,直到拥有有效的对策,可以持续地缩短反馈周期和放大反馈环,这是所有现代流程优化方法的一个核心原则,能够创造出组织学习与改进的机会。

    第三步,建立具有创意和高可信度的企业文化,支持动态的、严格的、科学的实验。通过主动地承担风险,不但能从成功中学习,也能从失败中学习。通过持续地缩短和放大反馈环,不仅能创造更安全的工作系统,也能承担更多的风险,并进行试验帮助自己比竞争对手改进得更快,从而在市场竞争中战胜他们。

    作为第三步的一部分,我们能够让工作系统事半功倍,将局部优化转化为全局优化。另外,不管是谁参与了工作,所有经验都可以持续地积累,组织里的人都可以相互借鉴彼此的经验和智慧。

    1.4 小结

    本章描述了价值流的概念,同时还介绍了制造业价值流和技术价值流中的一个重要量度指标——前置时间,最后介绍了三步工作法(支撑 DevOps 的原则)的基本概念。

    在后续的章节中,我们将更详细地描述三步工作法。第一步是流动原则,不管是在制造行业还是在信息技术产业,它都聚焦于在价值交付过程中建立快速的工作流。关于快速流动的更多实践,将会在本书的第三部分详细描述。


    [1] 从目前开始,工程师指的是在我们的价值流中的任何工作者,而不仅仅指开发人员。

    [2] 事实上,使用类似测试驱动开发的技术,测试甚至可以发生在编写第一行程序代码之前。

    [3] Karen Martin 和 Mike Osterling 曾说:“为了避免混淆,我们不使用‘循环时间’这个词,因为它还有其他的同义词——处理时间、输出速率或输出频率等。”同理,本书中主要使用“处理时间”一词。

    导言:展望 DevOps 新世界
    第2章 第一步:流动原则
    第3章 第二步:反馈原则
    第4章 第三步:持续学习与实验原则
    第二部分 从何处开始
    第5章 选择合适的价值流作为切入点
    第6章 理解、可视化和运用价值流
    第7章 参考康威定律设计组织结构
    第8章 将运维融入日常开发工作
    第三部分 第一步:流动的技术实践
    第9章 为部署流水线奠定基础
    第10章 实现快速可靠的自动化测试
    第11章 应用和实践持续集成
    第12章 自动化和低风险发布
    第13章 降低发布风险的架构
    第四部分 第二步:反馈的技术实践
    第14章 建立能发现并解决问题的遥测系统
    第15章 分析遥测数据以更好地预测故障和实现目标
    第16章 应用反馈实现安全部署
    第17章 将假设驱动的开发和 A/B 测试融入日常工作
    第18章 建立评审和协作流程以提升当前工作的质量
    第五部分 第三步:持续学习与实验的技术实践
    第19章 将学习融入日常工作
    第20章 将局部经验转化为全局改进
    第21章 预留组织学习和改进的时间
    第六部分 集成信息安全、变更管理和合规性的技术实践
    第22章 将信息安全融入每个人的日常工作
    第23章 保护部署流水线
    行动起来——本书总结
    附录
    参考资料
    致谢
    EXIN DevOps Professional 认证备考指南&模拟题(上)
    EXIN DevOps Professional 认证备考指南&模拟题(下)

    阅读全文: http://gitbook.cn/gitchat/geekbook/5b710366dcc9492d20823772

    展开全文
  • DevOps 笔记

    2018-10-23 16:59:11
    云计算,容器,微服务更加促进了DevOps,同时DevOps也使这些技术的优势能够最大化的发挥。 DevOps 能给用户带来什么? 加快部署到生产环境的速度,由周/天改善为小时/分钟。 使部署对组织来说变成是日常和低...

    持续集成

    • 通过尽早的/经常的做代码集成,构建,部署,测试,降低软件开发风险。

      通过经常集成,构建,部署,测试,使问题尽早暴露出来,节约修复问题的时间。这里的问题包括但不限于:bug,安全,可靠性,代码风格合规性等。

    • 通过自动化的手段最大化降低部门墙对效率的影响。降低不同工种之间的依赖性。从而提高整体流程的效率。
    • DevOps 借鉴了精益制造的理念,在生产制造业中流水线用来制造产品,如生产汽车的流水钱。在软件开发领域,流水线制造的产品是可交付的软件。
    • DevOps tools 本身不是最重要的,最重要的是你如何使用这些工具。

    DevOps 三大原则

    目标是降低需求(或变更)交付到生产环境为止所需的时间,以及提高交付的服务的质量和可靠性。

    流动:将idea转化成服务的价值流。(from concept to cash)

    反馈:

    第二种方法,是一个反馈的闭环。就是在组织的各个部分之间创建,缩短和放大反馈循环。反馈循环这个术语最初来源工程控制系统。短期,高效的反馈循环是高效的产品研发,软件开发和运维的钥匙。用一个简单的bug来描述,如果这个bug是开发人员在把代码提交到控制系统之前发现,而不是通过测试人员发现的。这样的话,修改和修复问题的时间就节约了很多时间。如果这个bug是被QA人员发现的,而且被放在bug系统中跟踪,提交了bug给指给开发去修复。虽然这样bug最终还是修复了,但是过去了很长时间,即浪费了很多时间。如果这个bug在软件发布之后被用户发现,直接影响终端用户,然后客户反馈到公司,然后反馈到开发人员手中,开发人员去修复bug,这样会浪费更长时间,这样浪费了时间也相应消耗了更多金钱。

    文化:持续改善,持续学习

    • 相比于畏惧出错/重于惩罚的文化,高度信任和协作的文化更加被推崇。只有这样,有些问题点才会被提出来而不是装作不知道被藏起来。毕竟,我们只有先看到问题才能去解决这些问题。同时即使当问题发生的时候,启动的也不是问题追责机制,而是无追责的事后检讨或者反省活动,不是为了惩罚某人,而是为了避免下次同样的问题再次出现,组织级别的学习和成长使用这种方式不断展开。这是一个理想的状况,各种企业都在使用自己的方式去实现自己的DevOps.
    • 有些组织在构建企业文化时,一边拿着鞭子抽打,另一方面期待员工能够为公司殚精竭虑,所有问题都能畅所欲言,不太现实。
    • 弱化某一个点的贡献,如开发,QA,运维的单点的贡献。强调由各类工种协同工作完成组织的整体目标。

    在典型的DevOps实践的过程中,可以使用五步聚焦法确认对象和进行改善。比如为了降低交付时间,需要改善的对象(Constraint)一般如下:
    在这里插入图片描述
    云计算,容器,微服务更加促进了DevOps,同时DevOps也使这些技术的优势能够最大化的发挥。

    DevOps 能给用户带来什么?

    • 加快部署到生产环境的速度,由周/天改善为小时/分钟。
    • 使部署对组织来说变成是日常和低风险的作业。

    DevOps 训练游戏

    减小批次大小(模拟游戏)

    作业内容的批次的大小会对交付和产生浪费的根源的等待产生什么样的影响呢?可以通过“envelope game”来研究一下。“envelope game”游戏是James P. Womack 和 Daniel T. Jones在”Lean Thinking: Banish Waste and Create Wealth in Your Corporation”中提到的一个很有趣的游戏。
    拿“envelope game”这个精益练习中常用的游戏为例,可以很容易地看出批次大小的调节能够对交付产生的影响。游戏的内容简单说明如下:
    在这里插入图片描述
    使用不同的方式,Large Batches把Step 1的内容完成之后,才开始全部做Step 2的内容。而Single-Piece方式则是一个每次一小步。具体的等待和交付的情况如下图所示:
    在这里插入图片描述
    可以看出,Single-Piece很快就可以稳定地提供交付成果了。有Agile经验的开发者可能会立即意识到这在很大程度上简单展示了传统开发方式和Agile在价值交付方面差别。正是这样,“小步快跑”避免摔跟头,有问题也可以及时调整,这正是减小批次大小的意义所在。

    展开全文
  • Azure DevOps实用工具 该存储库包含实用程序脚本,用于在Azure中运行/配置DevOp系统。 这些脚本可以单独使用,但也可以在几种“入门”解决方案中加以利用: 内容 共同 :创建Azure服务主体凭据。 :部署针对...
  • 恰巧2020年也考取了DOM,借此机会,聊聊DevOps这个话题。由于这个话题过大,一篇博文肯定写不完,那么分成几次来写吧。这篇,先写DevOps的方法论。 DevOps产生的背景和解决的问题 程序员写出的代码,生产的软件...
  • 帮助盈利/提升文化/加速效率是DevOps实践的三大目标,上世纪八十年代在制造业领域展开的那场如火如荼的精益实践的变革还历历在目,而DevOps在软件领域将要或者已经掀起的风浪也是如出一辙。
  • devops_关于DevOps的故事

    2018-10-22 03:16:08
    devops 发展与运营的寓言 Amstrad基本阵列, 复习 很久以前,在过去的三十年里,在曼彻斯特北部一个破旧的磨坊小镇里,两个大人和一个孩子围坐在议会大厦的黄色Formica桌子旁,打开礼物,并互相祝福。 一个新...
  • 楼+ Linux 运维与 DevOps 实战挑战参考答案 本项目存放的是 课程 所有挑战的参考答案,需要的同学可以下载。按周分目录,每周下的挑战编号表示该挑战在该周的序号(从 1 开始,包括实验和挑战)。注意,挑战编号跟...
  • 这是我的现代DevOps课程练习的集合。
  • DevOps落地实践:Azure

    千次阅读 2020-01-09 07:54:10
    借助简单可靠的工具以更快的速度交付创新,实现持续交付。Azure中提供了一些列的工具来支撑DevOps能力的提供,在这篇文章中来对现状进行整体的梳理和确认。
  • Devops 的介绍

    万次阅读 2020-01-15 12:24:28
    一:DevOps 是什么 DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发...
  • devops定义 随着DevOps在CI和CD工具的帮助下逐渐成熟,角色和职责不断变化。 对于开发人员而言,这种向DevOps文化的演变提供了一个机会,使人们可以更好地了解每个决策如何影响软件生命周期。 有了更多的知识,就...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,581
精华内容 1,432
关键字:

devops作业