A box of chocolate

目前在国外，互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、Microsoft、SAP等，亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps究竟是怎样一回事？在Puppet、RightScale分别DevOps出版的调查报告基础上，整理本文，以期为读者理清思路。另外，中国正在开展了一份自己的调查问卷，由南京大学发起，欢迎大家投票参与。 DevOps是什么？从哪里来？ DevOps的概念 DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。 DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生。 DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。 换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。 历史变革 由上所述，相信大家对DevOps有了一定的了解。但是除了触及工具链之外，作为文化和技术的方法论，DevOps还需要公司在组织文化上的变革。回顾软件行业的研发模式，可以发现大致有三个阶段：瀑布式开发、敏捷开发、DevOps。 DevOps早在九年前就有人提出来，但是，为什么这两年才开始受到越来越多的企业重视和实践呢？因为DevOps的发展是独木不成林的，现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。 （注：上图摘自上月红帽副总裁Ashesh Badani的一次新闻分享会） DevOps的几个关键问题 好处是什么？ DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告，根据全球4600位各IT公司的技术工作者的提交数据统计，得出高效公司平均每年可以完成1460次部署。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。 DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。 快速部署同时提高IT稳定性。这难道不矛盾吗？...

本篇文章来自于HPE和msup共同举办的技术开放日HPE测试技术总监肖俊的分享，由壹佰案例整理编辑。 一、DevOps含义解析 这是DevOps的趋势图。DevOps这个概念大概是在2009年被提出来的，2010年有一些公司开始试点，之后DevOps的热度持续增加，这是我们在谷歌搜索DevOps关键字得到的搜索量，这条曲线表示了DevOps热度呈指数级增长。因此我预计2016年DevOps仍然会成为一个非常受关注的技术。 什么是DevOps？ 我们在试点DevOps的时候做了很多研究，也在网上做了很多搜索。比较普遍的说法是：DevOps是一种文化，用以打破开发、运维以及测试之间的工作壁垒。之所以会有壁垒是因为开发、测试、运维的工作职责、目的存在不一致性。比如开发的主要目的是赶紧实现业务级的新需求及功能，交给客户使用，然后根据反馈信息继续更新；运维的主要目的是生产必须快速、不能出问题，所以他们不是很喜欢“变化”，因为变化可能会带来风险，随之而来的就是各种问题，这是他们最不愿意看到的。 如果站在他们各自的角度来看，这些考虑都很正确，但现在的市场要求所有研发人员的最终目的都是“帮助业务部门创造商业价值”，而不只是狭隘地满足各自的目标。如何创造商业价值？充分满足客户的需求。客户的需求是多变的，而且变化的速度很快，这就要求我们必须跟上他们的步伐，快速实现最新功能并交给客户使用，如果一个系统很稳定但没有人使用，那它一样不能给我们带来任何东西。 维基百科上对DevOps的解释是：软件开发人员和IT运维技术人员之间沟通合作的文化、趋势或实践。透过自动化（软件缴付）的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。之前开发、测试、运维三者之间可能是独立的，现在要求更紧密一点。一句话总结，DevOps就是：开发测（试）（运）维融一体，敏捷高效自动化。这也是我们对DevOps的定义和理解。 自2009年提出DevOps的概念起，很多公司都开始实施DevOps，国外比较著名的有Google、Facebook等，国内著名的有百度、华为、阿里、Flickr等，他们实施DevOps的结果是每天有10次部署，这是非常了不起的。 二、HPE IT在DevOps上的实践 HPE IT部门在2014年年底的时候引入DevOps概念，2015年找了一些内部的敏捷项目做试点，2016年我们开始在400多个应用里推广DevOps。 1、引入DevOps的实际背景 既然要实践要推广，我们看一下目前的现状。IT在开发的流程上使用敏捷已经很久了，所以可以看到，开发实际上采用了敏捷的迭代方法，每个冲刺都会产出一个可发布的产品。到了运维这边，我们不得不遵循企业发布规则：每三个月一次发布窗口，我们就必须等待。根据应用的技术不同，有不同的运维团队来帮助你做生产环境的部署和监控，所以我们得找到相应的运维团队，提前7天提交一个rfc。这些流程做完之后，运维团队开始部署，这时要写一个“部署文档”告诉他怎么上传到服务器，把哪个文件删掉、哪个文件备份等，我看到最大的可能有十几页，很多时候运维人员要管很多项目，部署又有问题。整个流程非常繁琐，敏捷在实现在开发中的运用，但在运维中仍然不足。最后我们看到“部署”变成最后一公里，最后一公里如果没法做到“敏捷”的话，前面的“敏捷”可能就白做了。 2、DevOps持续交付、持续部署 为了解决这些问题，我们提出了一个DevOps的方案，通过持续交付和持续部署来实现。持续交付和持续部署大体上包括了4个部分：1.开发和开发相关的；2.QA测试相关；3.用户测试相关；4.生产运维相关。通过整个的DevOps持续集成、持续交付把开发、测试、运维三者都包括其中。 开发环节的持续集成 我们强调每一个开发人员做的任何修改，必须得在本地通过新功能的单元测试。通过了新功能的单元测试后会做整合，然后提交到代码仓库，一旦提交代码到代码仓库，我们的服务器会自动触发，做自动化构建和比较全面的单元测试，然后再做部署到itg上面，如果这个新的代码通过了itg的测试就会显示时绿色的，没通过会显示是红色的。 有的时候开发很着急，不断写新代码希望做得快一些，不注意细节，QA就觉得很难理解，有的时候甚至构建不起来，提交过来也没办法部署。举个例子，我们要求所有代码都是小写，有一次我们的开发用了第三方的一些库文件，而这个第三方的库文件中间会有大写的字母，这些大写的字母出现在配置文件中，到部署时就可能导致QA环境出错。因为我们的QA环境是Liunx的系统，对大小写比较敏感。 开发经常说：“在我这边是好的，是你的问题，不是我的问题。”为了避免这样的状况出现，我们要求必须得在itg上做测试，这个itg和生产环境比较类似，都是Liunx。 代码分支策略：单分支结构 接下来介绍一个我们的分支策略。我们的代码分支策略叫单分支结构，这样的好处有： （1）如果在开发时有太多的分支，最后合并会很麻烦。每一次合并分支开发人员都要花少则半个小时到一个小时，多则半天到一天的时间，合并好以后测试人员再做回归测试。整个流程下来，一天就过去了，所以我们不太赞成有太多的分支。 （2）我们持续集成的服务是监控主干的，主干上有任何代码提交都会发现。如果我们不去看这些分支，这些分支就不做持续集成，这样的风险很大。 这是我们分支的策略，我们要求每个开发每天至少要提交一次代码到代码仓库。每天提交、每天做测试就不会那么容易出现问题；如果很久才做测试的话不仅会发现很多问题，而且修改起来非常费时间。我们可以做到大概每天1.5次/人的代码提交。...

操作系统及MySQL数据库的实时性能状态数据尤为重要，特别是在有性能抖动的时候，这些实时的性能数据可以快速帮助你定位系统或MySQL数据库的性能瓶颈，就像你在Linux系统上使用「top，sar，iostat」等命令工具一样，可以立刻定位OS的性能瓶颈是在IO还是CPU上，所以收集/展示这些性能数据就更为重要，那都有哪些重要的实时性能状态指标可以反应出系统和MySQL数据库的性能负载呢？ 目前在Linux跑MySQL是大多数互联网公司的标配，以上图片的性能数据指标项是我认为在Linux，MySQL，InnoDB中较为重要的实时状态数据，然而在以上图片Doing一栏其实更为重要，之所以把它叫做Doing，是因为「processlist，engine innodb status，locks」等指标项才真正反映了MySQL此时正在做什么。 我们来对标Oracle数据库看一下，在Oracle数据库中提供了「AWR，ASH，SQL Monitor」等众多诊断工具，可以一眼望穿数据库正在做什么，甚至都可以知道在过去30天内任何一个时间区间的性能负载和当时数据库正在做什么。 在MySQL中虽然有像「zabbix，PMM」等优秀的监控工具，但它们只能反映数据库历史的一些性能数据曲线，例如，TPS高了，临时表使用多了，有InnoDB Deadlocks，但对于MySQL当时的Doing，我只能说不够直接。如果你在现场，你可以抓到MySQL正在做什么，但是，你总有不在现场的时候，如果问你昨天晚上数据库的性能抖动是什么原因？怎样快速重现现场找到引起抖动的原因呢？ 答案是可以使用「doDBA tools」，这是一款免费的基于控制台监控工具。 doDBA tools是什么 doDBA tools是一个基于控制台的远程监控工具，它不需要在本地/远程系统上安装任何软件，它可以实时收集操作系统、MySQL、InnoDB的实时性能状态数据，并可以生成Doing日志文件，来帮助你快速了解/优化系统及MySQL数据库。 特点 基于golang语言开发 可收集Linux、MySQL相关性能数据 可本地或远程收集，可多台 mytop –Like Linux TOP 基于并发生成Doing日志，复现现场 可记录到日志文件 doDBA tools...

“互联网+”时代，软件产品要想满足快速增长的用户需求，高效、快速的迭代转型必不可少，面对时刻发生改变的互联网及业务模式需求，搭建高效的交付流水线更是势在必行。那么，如何构建一套能快速交付、保质又少风险的持续交付系统呢？   在Gdevops全球敏捷运维峰会北京站的讲台上，百度资深敏捷教练张乐便以持续支付为题，给现场带来了《解密百度持续交付方法与实践》的精彩演讲，独家分享百度在解决这方面问题和挑战时的最佳实践经验。   （点击“这里”听张乐演讲完整录音）   常言说，“工欲善其事，必先利其器”。百度持续交付体系如此高效的秘诀在于他们构建了一套符合业务发展的持续交付系统：通过建立一套持续交付实践框架和一条可靠可重复的流水线，辅以7种消除浪费与精益思想，在配置管理、构建管理、测试管理、持续集成、环境管理和部署管理六大核心实践的合力下，让整个交付变成一种标准化、自动化、可视化的过程。   如果说把敏捷作为一种精益思想是在需求研发阶段的一个实践，那DevOps就是精益在发布和运维阶段的一个实现。通过DevOps落地，百度让开发和运维紧密合作，形成合力，共同促进了价值的持续交付。                      

当我们谈到 DevOps 时，可能讨论的是：流程和管理，运维和自动化，架构和服务，以及文化和组织等等概念。那么，到底什么是”DevOps”呢？ 什么是DevOps 随着软件发布迭代的频率越来越高，传统的「瀑布型」（开发—测试—发布）模式已经不能满足快速交付的需求。2009 年左右 DevOps 应运而生，简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。 flow.ci 关于 DevOps 是什么，DevOps 的合著者 John Willis 写了一个非常好的帖子，在这里. Devops 的好处与价值 在2016 DevOps 新趋势调查报告显示，74% 的公司在尝试接受 DevOps，那么 Devops 有哪些好处与价值呢？...

DFF 20881 Customer 20882 Application 20883 Notification 20885 Sample 20886 System 20887 SystemInterface 20888 Quotation 20889

[ -a FILE ] 如果 FILE 存在则为真。 [ -b FILE ] 如果 FILE 存在且是一个块特殊文件则为真。 [ -c FILE ] 如果 FILE 存在且是一个字特殊文件则为真。 [ -d FILE ]...

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!