DevOps的真谛到底是什么?

摘要:DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。虽然DevOps对初创公司来说很明显是不可或缺的,但那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。 最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。 这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。 请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。 但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。 与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。 最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。 本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。 DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。 虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。 本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158 目录 DevOps的真谛到底是什么? 简介1.1 管理信条1.2 一个典型的IT组织1.3 运维人员测挫败感1.4 基础架构自动化1.5 DevOps:仅此一次,一颗神奇的银子弹 基础架构即代码2.1 概述2.2 DevOps工具链2.3 收益 持续交付3.1 从实践中学习3.2 自动化3.3 更频繁的部署3.4 持续交付的前提需求3.5 零停机部署 协作4.1 混乱之墙4.2 软件开发流程4.3 共享工具4.4 协同工作 结论 1. 简介 DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。 开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。 开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。 DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。 令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来! 而这恰恰正是DevOps所要达成的唯一目标! 但在进一步讨论这一点之前,首先需要谈谈其他几件事。    1.1 管理信条 IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么? 有什么想法吗? 我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么? 当然是要加快上市时间(TTM)! 上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。 在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。 TTM通常也会被叫做前置时间(Lead Time)。 第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。 请容我来解释一下。 IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。 这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。  …

Read More

Scrum 实践总结终结篇

难得的机会 谢谢大家关注我的微信公众号vipdocker,到目前为止已经有过千的订阅数。虽然还很少,但是我会继续努力分享多多写点工作心得以及工作的技术思考来与大家交流。不过惭愧的是,最近的一些变化使得我已经尽3个月没有写文章了,抱歉抱歉! 个人最大的变化是新近换了新东家,借着给新东家的同事分享Scrum开发模式的机会,把这个系列的文章的终结篇给完成了,或许某些内容与之前的文章有些重复,不过又有了新的思考,欢迎翻阅与对比查看(可通过公众号的历史文章找到)。 本文主要涵盖的内容如下: 敏捷Scrum模式概貌 Scrum Team的组成与角色分工 团队的日常活动 敏捷Scrum模式概貌 开发管理的痛点 开发过程的各个环节的明确边际,造成信息传递链条过长,沟通成本以及问题反馈效率低。现行的多数团队,其沟通方式多数是链式传递的,从产品->架构->开发->测试这样一个过程。然后就是每个人都希望做完自己规定的职责后可以当甩手掌柜,最后结果是下游环节在出现问题的时候把责任习惯性推给上游环节。测试不管大局,拼命找开发的所谓的“漏洞”,而开发则去说架构没有设计好,架构则找产品茬说产品啥YY需求。这样最明显的特征就是测试似乎绩效很好,但是产品质量依然一塌糊涂。这里引出一个公司管理的一个很现实的问题,在小团队规模开发模式下,以个人还是以团队的方式考核KPI和事? 新技术的引入(微服务、容器化),不再适应大军团作战,而是需要匹配的灵活的端到端团队。在一个分层比较多的组织里面,最难做到的是管理水平化,往往在团队外增加“保姆式”的组织或监控流程。这样团队除了日常的工作,还要疲于应付那些水平管理所带来的沟通、会议等。这样整个团队都在疲于加班,但是事情依然无法按时完成。 客户的需求变化已经不再局限于整体产品购买,而是倾向于业务快速迭代,大军团作战已经难以快速交付、快速变更。如何配合客户的业务变更成为传统大型产品销售型企业最大的挑战。因为一个客户的产品已经难以复制性再交付给下一个客户了。在这样的市场条件下,如何将系统更大程度的拆解与灵活组装考验架构设计能力,也同样考验开发组织形式的变更能力。 敏捷开发不是个新鲜事物,但是随着微服务、容器化等新技术理念的推出,敏捷开发找到了更合适的切合点而已。 什么是Scrum敏捷开发 几个值得思考的问题: 团队对于需求范围是否有自主性? 开发范围是否是根据时间倒排? 是流程管控开发人员,还是人主导流程? 在有市场交付压力的团队中,最容易遇到的问题就是倒排时间。因为交付内容与交付日期已经先确定了,然后当遇到开发瓶颈的时候,第一个想到的就是给团队增加人手。但是别忘了一个经典的说法,一个女人生一个孩子需要9个月,那么9个女人是否可以一个就生出一个孩子呢?答案是显而易见的。另外一个说法就是,如果所有的需求都是高优先级的,那么所有的需求都是低优先级的。 具体什么是Scrum敏捷开发,大家可以参考一下这本书:<<Successding with Agile Software Development with Scrum>> 不过还是跟大家强调一点,流程是死的,人是活动,需要根据团队情况进行变通。 区别 现在已经不流行敏捷开发,而是流程DevOps了。其实可以这样说,不以敏捷开发为基础的DevOps都是耍流氓。 Scrum不是等同DevOps,也不等同与现在更流行的SRE的概念。(具体SRE是什么,大家可以搜索一下)。DevOps和SRE将运维管理引入到开发团队中,将运维情况与开发形成一个闭环,是开发更能有效的考虑实际使用情况。个人理解,其三者的关系如下图: “scrum vs devops vs sre” 困境 虽然很多时候,大家都觉得敏捷开发, DevOps等理念都很好,但是就是很难去实行,最大的借口就是原来需要做的事情太多。但是这个时候,无论是团队还是管理者,需要停下脚步,做下思考,因为你遇到的情况很可能与下面这个图类似(来自互联网): “hard work” 公司形态与Scrum模式 不同的公司业务形态是否Scrum的方式都一样呢?我的理解是核心是相通的,方式是灵活适配的。主要分为两种主要形态: 自运营或服务形式提供 B2B模式的产品开发 自运营/服务模式Scrum流程概貌 参考下图: “operation mode” 在自运营的场景下,市场人员和产品的策略管理者(SPM)来探讨大的产品方向,然后业务分析师(BSA)做相应的规划,然后各个子产品Owner,俗称Product Owner(PO)根据这些输入制定各自产品的Backlog,然后规划各自产品的迭代。这里引出一个问题,怎么将抽象的需求或者业务需求拆解到各个子产品中呢?一般的做法是顶层有对应的架构师(俗称首席架构师),他来规划产品的边界,与大的需求的拆分。但是这样的人比较难找,因为他既要懂得业务,还要设计整体体系的架构,还要能分解需求边界等等。如果你遇到这样的人,千万不错过。 在自运营或者以服务的形式向客户提供支持的场景下,每个子产品的PO自行规划迭代范围,自行规划上线时间。不是所有的特性都要完成才能上线。对于跑的快的团队,其实可以将某个需要别的子产品配合的特性的提前上线的,尽管这个特性还没有真正能使用。对于产品关联依赖的特性,则可以通过PO间的Scrum2Scrum协调解决。(后面讲) B2B的Scrum流程概貌 参考下图: “b2b mode” 在B2B的产品销售模式下,很难做到各自独立的子产品对客户发布,因为客户需要的是一个Turn Key的交钥匙模式。在这种模式下是否就不可以做到敏捷开发呢?其实也不然。 和前面的自运营模式不同的是,各个子产品不会发布到生产环境中,但是各个子产品依然可以根据自己的节奏做发布。只是需要在特定的时间,将各个子产品的组合起来做一次基线测试和联调,出一个整个产品的基线版本就好。这里需要主要的是,不用拉齐各个产品的版本节奏,而是根据时间点对不同的子产品做版本选择就好。另外集成测试团队只是在需要的时候临时组建,而不是固定的团队。切记,平时这些集成测试的人员应该在各个子产品的团队中。各个子产品间的集成测试应该在功能特性完成时就独立去做了。这个基线测试更像是集成的回归测试。 Scrum…

Read More

如何删除docker images/containers

docker images往往不知不觉就占满了硬盘空间,为了清理冗余的image,可采用以下方法: 1.进入root权限 sudo su 2.停止所有的container,这样才能够删除其中的images: docker stop $(docker ps -a -q) 如果想要删除所有container的话再加一个指令: docker rm $(docker ps -a -q) 3.查看当前有些什么images docker images 4.删除images,通过image的id来指定删除谁 docker rmi <image id> 想要删除untagged images,也就是那些id为<None>的image的话可以用 docker rmi $(docker images | grep “^<none>” | awk “{print $3}”) 要删除全部image的话 docker rmi $(docker images -q)

查询每个子目录所占用的空间大小

cd到上级目录,然后输入一条命令即可查询每个子目录所占用的空间大小 du -h –max-depth=1 Linux学习,http:// linux.it.net.cn 可以更改–max-depth参数的值,该参数表示查询子目录的层级,当前为1层

Quick Guide to Developing Microservices on Kubernetes and Docker

http://www.eclipse.org/community/eclipse_newsletter/2017/january/article2.php   As Java developers we’re often really busy with large backlogs, customer issues and countless disruptions. It can be quite daunting finding the time to learn all about things like Kubernetes and its associated tools and technologies (kubectl, OpenShift, oc, Docker and Rkt and standards like CNCF and OCI). Its well worth doing if you have the time mind…

Read More

Pipeline as Code with Jenkins

The default interaction model with Jenkins, historically, has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires additional effort to create and manage jobs to test and build multiple projects, it also keeps the configuration of a job to build/test/deploy separate from the actual code being…

Read More

Achieving CI/CD with Kubernetes

Hola amigos !!(In English – Hello Friends !!) Hope you are having a jolly good day ! Continous Integration/Delivery is best said in terms of Martin Fowler,according to him it can be defined as, “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to…

Read More

Installing Kubernetes Cluster with 3 minions on CentOS 7 to manage pods and services

Note: This post updated on 28th April 2015 with updated installation steps. Kubernetes is a system for managing containerized applications in a clustered environment. It provides basic mechanisms for deployment, maintenance and scaling of applications on public, private or hybrid setups. It also comes with self-healing features where containers can be auto provisioned, restarted or even replicated. Kubernetes is still…

Read More

CentOS

Prerequisites To configure Kubernetes with CentOS, you’ll need a machine to act as a master, and one or more CentOS 7 hosts to act as cluster nodes. Starting a cluster This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc… The Kubernetes package provides a…

Read More

Linux 笔记

一、基础 1、基础命令 tty : 查看当前终端类型 返回值 终端类型 /dev/pst/# 伪终端 /dev/tty# 虚拟终端 /dev/console 物理终端 /dev/ttys# 串行终端 who : 查看登录用户 bashname : 查看目录基名 dirname : 查看目录名 type : 查看命令类型 where : 命令在哪(zsh) hash : 查看命令缓存 which : 查看命令所在位置 man : 查看命令帮助,可为 命令、程序配置文件格式、系统调用、库调用、游戏及其他不便归类的文件提供操作手册,以下为 man 下的快捷键: space : 向下翻屏 b : 向上翻屏 Enter : 向下翻一行 k : 向上翻一行 /:keyword : 向下查找文字 ?:keyword : 向上查找文字…

Read More