如何保证SDDC的安全问题不容忽视

OT学习平台 发表了文章 • 0 个评论 • 475 次浏览 • 2017-08-03 16:17 • 来自相关话题

软件定义数据中心(SDDC)是根据硬件和软件的抽象而提出的一种将数据中心作为由软件层控制和管理的大量物理和虚拟资源的全新的方式。然而,很多企业在实际实施SDDC的过程中或多或少的遇到了一些安全问题。




使用SDDC虚拟化服务器、网络和存储,安全是阻止企业使用完全成熟的软件定义数据中心的主要障碍。虽然SDDC的发展趋势被普遍看好,例如增加采用率和更快的部署将显著提高采用率,但软件定义数据中心将面临更多地数据泄露问题。
向完全虚拟化的基础设施的过渡是渐进的,没有人期望能在短期内实现虚拟化。软件定义数据中心(SDDC)、软件定义基础设施(SDI)、软件定义网络(SDN)和软件定义存储(SDS)都是企业的长期战略目标。然而大多数的企业将使用自上而下的方法实施,即从SDDC和SDI开始,而不是自下而上的从SDN和SDS开始。
根据Gartner对2018年的预测,这种大规模部署SDDC也可能引起广发的数据安全管理计划,20%的企业认为这是非常有必要的,可以有效防止数据泄露。TMC的执行编辑Paula Bernier在最近的一篇文章中指出,根据Gartner的预测,到2020年SDDC将被认为是实现DevOps方法和混合云模型的全球2000家企业中75%的企业的需求。
  查看全部
软件定义数据中心(SDDC)是根据硬件和软件的抽象而提出的一种将数据中心作为由软件层控制和管理的大量物理和虚拟资源的全新的方式。然而,很多企业在实际实施SDDC的过程中或多或少的遇到了一些安全问题。
SDDC.jpg

使用SDDC虚拟化服务器、网络和存储,安全是阻止企业使用完全成熟的软件定义数据中心的主要障碍。虽然SDDC的发展趋势被普遍看好,例如增加采用率和更快的部署将显著提高采用率,但软件定义数据中心将面临更多地数据泄露问题。
向完全虚拟化的基础设施的过渡是渐进的,没有人期望能在短期内实现虚拟化。软件定义数据中心(SDDC)、软件定义基础设施(SDI)、软件定义网络(SDN)和软件定义存储(SDS)都是企业的长期战略目标。然而大多数的企业将使用自上而下的方法实施,即从SDDC和SDI开始,而不是自下而上的从SDN和SDS开始。
根据Gartner对2018年的预测,这种大规模部署SDDC也可能引起广发的数据安全管理计划,20%的企业认为这是非常有必要的,可以有效防止数据泄露。TMC的执行编辑Paula Bernier在最近的一篇文章中指出,根据Gartner的预测,到2020年SDDC将被认为是实现DevOps方法和混合云模型的全球2000家企业中75%的企业的需求。
 

云迁移过程中如何保证数据安全性

OT学习平台 发表了文章 • 0 个评论 • 532 次浏览 • 2017-08-02 16:48 • 来自相关话题

由于成本的降低和业务的便捷性,越来越多的企业将自己的IT系统迁移到云端,而在迁移的过程中,从基础设施的部署到云平台的挑战都十分的具有挑战性,在迁移过程中,企业IT管理着最需要重视的一个问题就是:如何保证云迁移的安全,减少迁移风险。
为了降低向云端迁移的风险,保证数据的安全性,OTPUB认为企业可以通过下面三种方法着手策划数据向云的迁移。 
第一种方法是指将本地硬件或虚拟机上的数据迁移到与之相匹配的云上。该解决方案缺乏弹性,该方案通常是为了满足峰值负载而过度供应,这就会导致了云计算成本的增加,因此这种方法作为一种短期解决措施会更佳。
第二种方法是指对企业的应用技术进行重新架构。数据迁移需要花费一定时间,而且具有较强的强制性,而对企业技术进行重新架构反而会获得更好的性能。的确,重新对应用技术的选择进行评估也不失为一种更好的选择。因为企业可能会将一些解决方案从使用昂贵的商业软件转向开源产品上来。
第三种方法是搁置单一的本地应用程序,将程序内部数据迁移到SaaS。这种方法既实现了业务的现代化标准,又将基础架构和服务的运营负担转嫁给了SaaS提供商。
以上三种方法可以让企业在最佳情况下完成数据由本地向云端的迁移,同时最大限度的保证了迁移过程中数据的安全性。 查看全部
由于成本的降低和业务的便捷性,越来越多的企业将自己的IT系统迁移到云端,而在迁移的过程中,从基础设施的部署到云平台的挑战都十分的具有挑战性,在迁移过程中,企业IT管理着最需要重视的一个问题就是:如何保证云迁移的安全,减少迁移风险。
为了降低向云端迁移的风险,保证数据的安全性,OTPUB认为企业可以通过下面三种方法着手策划数据向云的迁移。 
第一种方法是指将本地硬件或虚拟机上的数据迁移到与之相匹配的云上。该解决方案缺乏弹性,该方案通常是为了满足峰值负载而过度供应,这就会导致了云计算成本的增加,因此这种方法作为一种短期解决措施会更佳。
第二种方法是指对企业的应用技术进行重新架构。数据迁移需要花费一定时间,而且具有较强的强制性,而对企业技术进行重新架构反而会获得更好的性能。的确,重新对应用技术的选择进行评估也不失为一种更好的选择。因为企业可能会将一些解决方案从使用昂贵的商业软件转向开源产品上来。
第三种方法是搁置单一的本地应用程序,将程序内部数据迁移到SaaS。这种方法既实现了业务的现代化标准,又将基础架构和服务的运营负担转嫁给了SaaS提供商。
以上三种方法可以让企业在最佳情况下完成数据由本地向云端的迁移,同时最大限度的保证了迁移过程中数据的安全性。

VMware克隆Centos主机后网卡信息配置详解

push 发表了文章 • 0 个评论 • 557 次浏览 • 2017-07-30 17:21 • 来自相关话题

在很多时候,我们利用VMware创建虚拟机做实验,我们一般都是需要多台主机的,这时候我们可以基于已经创建好的系统进行克隆。但是克隆之后我发现一个问题,那就是克隆出来的主机的网卡信息还是母机的信息,比如mac地址、UUID,而且会出现一块新网卡的信息,比如母机只有eth0网卡信息,而克隆出来的会多出eth1网卡的信息,但是实际克隆出来的主机也只有一块物理网卡eth0,下面我们就说说做可以让克隆出来的主机网卡信息正常,然后配置静态ip地址或者通过DHCP获取ip地址正常工作。
 

1、修改udev规则文件获取Mac地址

/etc/udev/rules.d/70-persistent-net.rules 这个文件跟你的网卡mac地址有关系,当你的网卡启动的时候这个文件会分配一个网卡名称给你的网卡。
 
# vim /etc/udev/rules.d/70-persistent-net.rules
该文件中正常此时应该有两行信息在文件中把 NAME="eth0″ 的这一行注释掉对于另一行,把 NAME=”eth1″ 的这一行,把 NAME=”eth1″ 改为 NAME=”eth0″,并且把该行:ATTRS{address}=="00:0c:29:58:0d:5a″ 这个属性信息记下来,后面修改Mac地址就使用这个。




 

2、修改eth0网卡Mac地址配置

为什么要修改,因为跟克隆母机的Mac地址一样,在同一个内网内会冲突,修改前:



# vim /etc/sysconfig/network-scripts/ifcfg-eth0把 HWADDR 的值改为上面要求记下来的:00:0c:29:58:0d:5a




到这里网卡的Mac地址已经修改完成,跟母机的不一样了,这样就不会冲突了。
 

3、获取并修改UUID

维基百介绍UUID:
通用唯一识别码(英语:Universally Unique Identifier,简称UUID)是一种软件建构的标准,亦为自由软件基金会组织在分散式计算环境领域的一部份。

UUID的目的,是让分散式系统中的所有元素,都能有唯一的辨识信息,而不需要通过中央控制端来做辨识信息的指定。如此一来,每个人都可以创建不与其它人冲突的UUID。在这样的情况下,就不需考虑数据库创建时的名称重复问题。目前最广泛应用的UUID,是微软公司的全局唯一标识符(GUID),而其他重要的应用,则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等。另外我们也可以在e2fsprogs包中的UUID库找到实现。
 
获取UUID:获取UUid我们可以通过两种方式,1是通过uuidgen命名,二是通过读取文件/proc/sys/kernel/random/uuid
 
我们这里功能uuidgen命名获取:
# a=`uuidgen eth1`
# sed -i "s@UUID.*@UUID=${a}@g" ifcfg-eth0



到这里就Mac地址和UUID都全部替换完成,跟母机的完全不一样了。
 

4、重启网卡获取IP地址

# /etc/init.d/network restart



如上图可以看出获取IP地址正常,Mac地址也是我们修改后的,好了到这里就都完成了,完成后,方便后面实验,最好新建的主机都创建初始的快照。 查看全部
在很多时候,我们利用VMware创建虚拟机做实验,我们一般都是需要多台主机的,这时候我们可以基于已经创建好的系统进行克隆。但是克隆之后我发现一个问题,那就是克隆出来的主机的网卡信息还是母机的信息,比如mac地址、UUID,而且会出现一块新网卡的信息,比如母机只有eth0网卡信息,而克隆出来的会多出eth1网卡的信息,但是实际克隆出来的主机也只有一块物理网卡eth0,下面我们就说说做可以让克隆出来的主机网卡信息正常,然后配置静态ip地址或者通过DHCP获取ip地址正常工作。
 


1、修改udev规则文件获取Mac地址


/etc/udev/rules.d/70-persistent-net.rules 这个文件跟你的网卡mac地址有关系,当你的网卡启动的时候这个文件会分配一个网卡名称给你的网卡。
 
# vim /etc/udev/rules.d/70-persistent-net.rules

  • 该文件中正常此时应该有两行信息
  • 在文件中把 NAME="eth0″ 的这一行注释掉
  • 对于另一行,把 NAME=”eth1″ 的这一行,把 NAME=”eth1″ 改为 NAME=”eth0″,并且把该行:ATTRS{address}=="00:0c:29:58:0d:5a″ 这个属性信息记下来,后面修改Mac地址就使用这个。

rules.png

 


2、修改eth0网卡Mac地址配置


为什么要修改,因为跟克隆母机的Mac地址一样,在同一个内网内会冲突,修改前:
ethago.png
# vim /etc/sysconfig/network-scripts/ifcfg-eth0
把 HWADDR 的值改为上面要求记下来的:00:0c:29:58:0d:5a
ethafter.png

到这里网卡的Mac地址已经修改完成,跟母机的不一样了,这样就不会冲突了。
 


3、获取并修改UUID


维基百介绍UUID
通用唯一识别码(英语:Universally Unique Identifier,简称UUID)是一种软件建构的标准,亦为自由软件基金会组织在分散式计算环境领域的一部份。

UUID的目的,是让分散式系统中的所有元素,都能有唯一的辨识信息,而不需要通过中央控制端来做辨识信息的指定。如此一来,每个人都可以创建不与其它人冲突的UUID。在这样的情况下,就不需考虑数据库创建时的名称重复问题。目前最广泛应用的UUID,是微软公司的全局唯一标识符(GUID),而其他重要的应用,则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等。另外我们也可以在e2fsprogs包中的UUID库找到实现。
 
获取UUID:获取UUid我们可以通过两种方式,1是通过uuidgen命名,二是通过读取文件/proc/sys/kernel/random/uuid
 
我们这里功能uuidgen命名获取:
# a=`uuidgen eth1`
# sed -i "s@UUID.*@UUID=${a}@g" ifcfg-eth0
uuid.png

到这里就Mac地址和UUID都全部替换完成,跟母机的完全不一样了。
 


4、重启网卡获取IP地址


# /etc/init.d/network restart
ipaddr.png

如上图可以看出获取IP地址正常,Mac地址也是我们修改后的,好了到这里就都完成了,完成后,方便后面实验,最好新建的主机都创建初始的快照。

7款不错的网站数据分析工具

koyo 发表了文章 • 1 个评论 • 1065 次浏览 • 2017-07-29 14:48 • 来自相关话题

拥有并运营一个很棒的网站不是一件简单的事情。除了需要决定网站的类型之外,你还需要运营网站,关注网站的各项数据并且决定使用何种手段增加流量。

你应该感到庆幸的是,这其实并没有那么复杂,但需要付出一些努力以及使用正确的工具。在这之后,你可以尝试使用各种不同的工具让工作流程更高效。

单靠一个工具是不可能完成所有事情的。所以要点在于要涉及各种不同的选择,比如分析工具、任务管理、流程自动化以及图形设计等。下面就列出了一些可以帮助站长提升品牌的最有价值的工具。
 

1、SE Ranking

SE Ranking 是一个基于云端的大而全的 SEO 服务。它帮站长减轻了不少负担,节约了生成报表的时间,同时在市场战略和发展计划的准备、分析以及调整等各个环节都很有帮助。

这个服务不仅仅是用来跟踪网站的排名,而且也可以用于各种复杂度的营销推广计划上。




SE Ranking 对这一代站长来说确实是一个非常有用也有很前景的 SEO 工具。尽管它在市场上还很新颖,但在实践中用起来还不错。

它里面有一系列很棒的功能,包括像关键词推荐、反向链接的监控,社交管理以及网站审计。我还没发现什么 SE Ranking的弱点,但我还是建议你尝试一下,也验证下所列出的各个功能的有效性。




 

2、Piktochart

Piktochart 是我最喜欢的在线信息图生成器,它可以让非专业设计师也能创建一些基本的设计图。如果没有时间或预算设计很好的信息图,那么就可以使用 Piktochart 把几个很赞的元素拼接起来生成想要快速进行病毒式传播的设计图。

Piktochart 是一个傻瓜式的工具,可创建不同的图表、地图和视频,而且它还有自动保存的功能。




基础版是免费的,但是只有一些有限的功能。你也可以使用解锁了所有功能的高级版。

如果你需要搜寻灵感和想法来创造出一些独特的东西,那么 Piktochart 就是你需要的工具。Piktochart 本身就充满了灵感,而且导航非常清晰易用。
 

3、Google Analytics

Google Analytics 是市场上最强大的分析服务之一。它可以让你分析流量,展示人口统计信息(年龄,性别等),另外也可以看到访客信息,包括新访客和回访访客。

不仅可以看到访客的地理位置,还可以发现他们在网站上做了什么。这样详细的人群统计信息也会帮助你预先计划网站未来的内容。




Google Analytics 是一个免费的网页版应用,只要有网络连接就可以随时随地使用。它的图表好看,而提供的结果也相当准确。另外它还可以在很多方面提供帮助,比如 A/B 测试和 Adwords 接入,这些都可以帮助提升用户体验。
 

4、Mention

Mention 是一个很不错的网络和社交媒体监控工具,其用户友好的界面非常简单易用。

该工具提供的免费套餐允许你每个月追踪最多500次品牌名字提及(@的次数)。如果你想追踪的提及次数超过500次,那么可以试试每月29美元起的高级套餐。




Mention 对于任何站长都绝对是节省时间的利器,因为你还可以再次转发这些推文,在 Facebook 页面上点赞或者分享积极的分享推文,以及通过 Email 发送推特文章。与其他工具相比,Mention 推送的通知非常地快,而且它还有一个很棒的功能就是可以在屏幕上预览结果。
 

5、Work Examiner

Work Examiner 可以帮助网站管理员管理很多项目。尽管有人会认为这侵犯了隐私,但是它作为一种监控员工的日常职责和收集员工工作时间的分配数据的方式还是相当有效的。通过这个工具,你可以限制员工访问某些可能会让他们分心的内容。




 

6、Ahrefs

Ahrefs 是从我开始 SEO 职业生涯以来就最喜欢的一个链接生成工具。该工具为站长分析链接信息提供了多个选项,可以让你知道一个网站的当前链接状态,并且可以帮助你理解网站内容和竞争对手。




在 Ahref 套装里,可以看到关键词分析,批量分析,站点探索,反向链接报表,域名比较以及竞争分析的工具。它高速的性能和图形化的展示甚至可以让SEO 新手都很容易地理解。




 

7、SEMrush

SEMrush 是一个为 SEO 专家和站长设计的多功能 SEO 工具,可用来研究客户的相关信息。该工具可让你全面了解客户,找到最佳关键词,排名超过竞争对手,检查他们的网站流量情况,找到所有的网站问题等等。

SEMrush 是一个一应俱全的 SEO 工具,提供了很多其他工具所没有的一系列有用的功能特性。




若想获得一份竞争对手网站全面又细致的分析数据,SEMrush 的高级账号会更好用些。 如果你是一个 SEO 初学者,你可以从免费试用账号开始,把 SEMrush 的所有有价值的功能全部体验一遍。




 

总结

网络上有很多为站长和网络营销人员提供的 SEO 工具。不管你是已经拥有了一堆网站,还是在创建一个网站的过程中,亦或是有了启动下一个大项目的计划,你都应该从上述7个工具里获得显著的好处。
 
分享英文原文:http://marketingland.com/top-7-must-tools-website-owners-165538 
 
  查看全部
WebSiteTools.png

拥有并运营一个很棒的网站不是一件简单的事情。除了需要决定网站的类型之外,你还需要运营网站,关注网站的各项数据并且决定使用何种手段增加流量。

你应该感到庆幸的是,这其实并没有那么复杂,但需要付出一些努力以及使用正确的工具。在这之后,你可以尝试使用各种不同的工具让工作流程更高效。

单靠一个工具是不可能完成所有事情的。所以要点在于要涉及各种不同的选择,比如分析工具、任务管理、流程自动化以及图形设计等。下面就列出了一些可以帮助站长提升品牌的最有价值的工具。
 


1、SE Ranking


SE Ranking 是一个基于云端的大而全的 SEO 服务。它帮站长减轻了不少负担,节约了生成报表的时间,同时在市场战略和发展计划的准备、分析以及调整等各个环节都很有帮助。

这个服务不仅仅是用来跟踪网站的排名,而且也可以用于各种复杂度的营销推广计划上。
Ranking.png

SE Ranking 对这一代站长来说确实是一个非常有用也有很前景的 SEO 工具。尽管它在市场上还很新颖,但在实践中用起来还不错。

它里面有一系列很棒的功能,包括像关键词推荐、反向链接的监控,社交管理以及网站审计。我还没发现什么 SE Ranking的弱点,但我还是建议你尝试一下,也验证下所列出的各个功能的有效性。
filter.png

 


2、Piktochart


Piktochart 是我最喜欢的在线信息图生成器,它可以让非专业设计师也能创建一些基本的设计图。如果没有时间或预算设计很好的信息图,那么就可以使用 Piktochart 把几个很赞的元素拼接起来生成想要快速进行病毒式传播的设计图。

Piktochart 是一个傻瓜式的工具,可创建不同的图表、地图和视频,而且它还有自动保存的功能。
Piktochart.png

基础版是免费的,但是只有一些有限的功能。你也可以使用解锁了所有功能的高级版。

如果你需要搜寻灵感和想法来创造出一些独特的东西,那么 Piktochart 就是你需要的工具。Piktochart 本身就充满了灵感,而且导航非常清晰易用。
 


3、Google Analytics


Google Analytics 是市场上最强大的分析服务之一。它可以让你分析流量,展示人口统计信息(年龄,性别等),另外也可以看到访客信息,包括新访客和回访访客。

不仅可以看到访客的地理位置,还可以发现他们在网站上做了什么。这样详细的人群统计信息也会帮助你预先计划网站未来的内容。
googlea.png

Google Analytics 是一个免费的网页版应用,只要有网络连接就可以随时随地使用。它的图表好看,而提供的结果也相当准确。另外它还可以在很多方面提供帮助,比如 A/B 测试和 Adwords 接入,这些都可以帮助提升用户体验。
 


4、Mention


Mention 是一个很不错的网络和社交媒体监控工具,其用户友好的界面非常简单易用。

该工具提供的免费套餐允许你每个月追踪最多500次品牌名字提及(@的次数)。如果你想追踪的提及次数超过500次,那么可以试试每月29美元起的高级套餐。
mention.png

Mention 对于任何站长都绝对是节省时间的利器,因为你还可以再次转发这些推文,在 Facebook 页面上点赞或者分享积极的分享推文,以及通过 Email 发送推特文章。与其他工具相比,Mention 推送的通知非常地快,而且它还有一个很棒的功能就是可以在屏幕上预览结果。
 


5、Work Examiner


Work Examiner 可以帮助网站管理员管理很多项目。尽管有人会认为这侵犯了隐私,但是它作为一种监控员工的日常职责和收集员工工作时间的分配数据的方式还是相当有效的。通过这个工具,你可以限制员工访问某些可能会让他们分心的内容。
workex.png

 


6、Ahrefs


Ahrefs 是从我开始 SEO 职业生涯以来就最喜欢的一个链接生成工具。该工具为站长分析链接信息提供了多个选项,可以让你知道一个网站的当前链接状态,并且可以帮助你理解网站内容和竞争对手。
ahrefs.png

在 Ahref 套装里,可以看到关键词分析,批量分析,站点探索,反向链接报表,域名比较以及竞争分析的工具。它高速的性能和图形化的展示甚至可以让SEO 新手都很容易地理解。
SiteEx.png

 


7、SEMrush


SEMrush 是一个为 SEO 专家和站长设计的多功能 SEO 工具,可用来研究客户的相关信息。该工具可让你全面了解客户,找到最佳关键词,排名超过竞争对手,检查他们的网站流量情况,找到所有的网站问题等等。

SEMrush 是一个一应俱全的 SEO 工具,提供了很多其他工具所没有的一系列有用的功能特性。
semrush.png

若想获得一份竞争对手网站全面又细致的分析数据,SEMrush 的高级账号会更好用些。 如果你是一个 SEO 初学者,你可以从免费试用账号开始,把 SEMrush 的所有有价值的功能全部体验一遍。
trial.png

 


总结


网络上有很多为站长和网络营销人员提供的 SEO 工具。不管你是已经拥有了一堆网站,还是在创建一个网站的过程中,亦或是有了启动下一个大项目的计划,你都应该从上述7个工具里获得显著的好处。
 
分享英文原文:http://marketingland.com/top-7-must-tools-website-owners-165538 
 
 

清除wnTKYg挖矿木马过程详解

chris 发表了文章 • 0 个评论 • 1122 次浏览 • 2017-07-27 23:02 • 来自相关话题

 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.




很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
把默认的端口号6379给改了把密码改的更复杂了把bind xx.xx.x.x xx.xx.xx.xx改了
修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉。
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500。
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :iptables -A INPUT -s xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文。 查看全部
 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.
wntky.png

很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
  1. 把默认的端口号6379给改了
  2. 把密码改的更复杂了
  3. 把bind xx.xx.x.x xx.xx.xx.xx改了

修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :
iptables -A INPUT -s  xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP
然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文

​腾讯云化解安全危机,开启网络安全智能时代

OT学习平台 发表了文章 • 0 个评论 • 469 次浏览 • 2017-07-26 16:02 • 来自相关话题

随着网络应用的广泛普及,信息安全问题日益严峻,信息泄密事件更是令许多企业和组织损失惨重。索尼(Sony)、塔吉特(Target)、摩根大通银行等公司在这方面都有过惨痛的教训。在传统网络安全防御模式下,许多企业即使投入了大量精力和资源,面对网络攻击时还是防不胜防。
不得不正视的问题:各行各业都在面临安全强大的挑战,无论是网络安全还是公司业务安全,包括金融、快消、游戏等行业。而腾讯云利用海量的防御体系、自身的防御以及大数据积累经验,来防御已发生和未发生的安全危机。
2016年大量的视频平台诞生,直播已经覆盖到各行各业,一个全民移动的直播时代已经来临。腾讯云依托快速接入视频点播平台,降低开发成本;点播产品高度融合CDN加速,提高用户观看视频体验;负载均衡保障用户接入冗余度等优势,为视频门户提供完善的视频服务。
此外,市场上电商平台也正面临着大促页面打不开、互动直播玩不转、黑产大军打不败、单IDC不容灾等难题。针对此类现状,腾讯云使用出“必杀技”,来解决传统运维效率低、成本高等问题,助力企业全面提升效率。
腾讯云如何利用自身优势来保护自有的业务安全?又是如何简易的搭建视频网站平台和腾讯云视频的?敬请关注7月27/28日14:00“视频网站/电商平台/金融/快消/游戏行业安全解决方案”直播活动。
点击直播名称进入直播间:“视频网站/电商平台/金融/快消/游戏行业安全解决方案” 查看全部
随着网络应用的广泛普及,信息安全问题日益严峻,信息泄密事件更是令许多企业和组织损失惨重。索尼(Sony)、塔吉特(Target)、摩根大通银行等公司在这方面都有过惨痛的教训。在传统网络安全防御模式下,许多企业即使投入了大量精力和资源,面对网络攻击时还是防不胜防。
不得不正视的问题:各行各业都在面临安全强大的挑战,无论是网络安全还是公司业务安全,包括金融、快消、游戏等行业。而腾讯云利用海量的防御体系、自身的防御以及大数据积累经验,来防御已发生和未发生的安全危机。
2016年大量的视频平台诞生,直播已经覆盖到各行各业,一个全民移动的直播时代已经来临。腾讯云依托快速接入视频点播平台,降低开发成本;点播产品高度融合CDN加速,提高用户观看视频体验;负载均衡保障用户接入冗余度等优势,为视频门户提供完善的视频服务。
此外,市场上电商平台也正面临着大促页面打不开、互动直播玩不转、黑产大军打不败、单IDC不容灾等难题。针对此类现状,腾讯云使用出“必杀技”,来解决传统运维效率低、成本高等问题,助力企业全面提升效率。
腾讯云如何利用自身优势来保护自有的业务安全?又是如何简易的搭建视频网站平台和腾讯云视频的?敬请关注7月27/28日14:00“视频网站/电商平台/金融/快消/游戏行业安全解决方案”直播活动。
点击直播名称进入直播间:“视频网站/电商平台/金融/快消/游戏行业安全解决方案

​移动互联时代,企业移动安全如何保证

OT学习平台 发表了文章 • 0 个评论 • 505 次浏览 • 2017-07-24 17:29 • 来自相关话题

智能手机等移动设备的普及将人们带入了移动互联网时代,同时,移动设备也越来越多的进入到企业办公之中,移动互联网为我们带来便利的同时也引发了关于移动安全的担忧,现在恶意软件以移动设备为依托,肆意传播,所以,控制恶意软件的传播刻不容缓,企业移动安全的问题不可忽视。
众所周知,Android设备相较于IOS设备的漏洞更多,主要是因为Android是一个开源的系统,每个独立的手机商都可以根据自己的需求对Android进行定制,而且应用的审核标准也比较低,这就成了恶意软件利用的目标;随着技术的发展,恶意软件的制作成本也越来越低,导致移动端的攻击行为逐渐规模化,而其主要载体会转向APP和APP插件。
任何智能手机都可以作为一个记录设备,这些设备上的数据泄露只要是因为其硬件可远程操控,另外,移动设备本身也可以作为发起攻击的媒介;攻击者会利用暗藏的恶意软件窃取个人或企业的敏感数据,它可能像间谍一样获取你的回忆记录、数据信息、甚至局域网或者可发现范围内的蓝牙设备的存储数据等。
企业移动安全应该主动防御
在企业移动化的过程中,应尽力确保移动应用的安全,因为企业移动化的很多功能都是基于移动应用来实现,而现在大多数开发者只注重产品的迭代和技术攻破,在应用安全性方面并没有投入太多的资源,这就造成了很大的安全隐患。
企业提升移动安全需要保持积极的态度,先做好员工安全意识教育,培养员工良好的使用移动设备习惯。
其次,企业在选择移动办公产品时,除了注重产品的品质和服务外,还应该注重产品的安全性。随着技术的发展,产品在技术和功能方面的差异越来越容易被复制和超越,而安全性不但是未雨绸缪的超前意识,更是一种负责任的严谨态度。
想要了解更多关于网络安全的知识,敬请关注7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您详解安全管理的未来发展趋势。
点击此处预约观看直播>>> 查看全部
智能手机等移动设备的普及将人们带入了移动互联网时代,同时,移动设备也越来越多的进入到企业办公之中,移动互联网为我们带来便利的同时也引发了关于移动安全的担忧,现在恶意软件以移动设备为依托,肆意传播,所以,控制恶意软件的传播刻不容缓,企业移动安全的问题不可忽视。
众所周知,Android设备相较于IOS设备的漏洞更多,主要是因为Android是一个开源的系统,每个独立的手机商都可以根据自己的需求对Android进行定制,而且应用的审核标准也比较低,这就成了恶意软件利用的目标;随着技术的发展,恶意软件的制作成本也越来越低,导致移动端的攻击行为逐渐规模化,而其主要载体会转向APP和APP插件。
任何智能手机都可以作为一个记录设备,这些设备上的数据泄露只要是因为其硬件可远程操控,另外,移动设备本身也可以作为发起攻击的媒介;攻击者会利用暗藏的恶意软件窃取个人或企业的敏感数据,它可能像间谍一样获取你的回忆记录、数据信息、甚至局域网或者可发现范围内的蓝牙设备的存储数据等。
企业移动安全应该主动防御
在企业移动化的过程中,应尽力确保移动应用的安全,因为企业移动化的很多功能都是基于移动应用来实现,而现在大多数开发者只注重产品的迭代和技术攻破,在应用安全性方面并没有投入太多的资源,这就造成了很大的安全隐患。
企业提升移动安全需要保持积极的态度,先做好员工安全意识教育,培养员工良好的使用移动设备习惯。
其次,企业在选择移动办公产品时,除了注重产品的品质和服务外,还应该注重产品的安全性。随着技术的发展,产品在技术和功能方面的差异越来越容易被复制和超越,而安全性不但是未雨绸缪的超前意识,更是一种负责任的严谨态度。
想要了解更多关于网络安全的知识,敬请关注7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您详解安全管理的未来发展趋势。
点击此处预约观看直播>>>

如何防范网络病毒的四点建议

OT学习平台 发表了文章 • 0 个评论 • 554 次浏览 • 2017-07-21 17:37 • 来自相关话题

自今年5月爆发wannacry勒索病毒以来,各种蠕虫病毒接踵而至,着实是让世界杀毒市场活了一把,“暗云Ⅲ”,Petya等等,一个比一个厉害,令人防不胜防,即使你染上了病毒也有可能完全不知情。
目前人们并没有养成很好的上网习惯,病毒预防的意识也很差,而且大多数用户更倾向于老旧版本的操作系统,以为旧的系统各方面都更加成熟,用起来也顺手,对于系统升级,维护方面有很强的抵触心理。






这里OTPUB小编就跟大家分享4个平时生活中预防网络病毒的建议。
1、安装杀毒软件,这一点相信大多数的人都做到了这一点;在使用杀毒软件的时候,建议开始病毒库自动更新,保证杀毒软件可以最快的识别网络上的新型病毒,另外,建议每周至少一次对个人电脑进行一些全盘病毒扫描,确保电脑没有隐藏的病毒。
2、使用基于客户端的防火墙或过滤措施,以增强计算机对黑客和恶意代码的攻击 的免疫力。或者在一些安全网站中,可对自己的计算机做病毒扫描,察看它是否存在安全漏洞与病毒。如果你经常在线,这一点很有必要,因为如果你的系统没有加设有效防护,你的个人资料很有可能会被他人窃取。
3、在使用外接设备(例如U盘,光盘,移动硬盘灯)时,先对其进行扫描,以防万一。
4、不安装来历不明的软件,下载软件要到官方指定的站点下载,切不可贪图省事去一些未知网站,以防下载的软件里面包含电脑病毒。
想要了解更多关于网络安全的知识,敬请关注7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您详解安全管理的未来发展趋势。
点击此处预约直播>>>
或扫描下方二维码预约 查看全部

自今年5月爆发wannacry勒索病毒以来,各种蠕虫病毒接踵而至,着实是让世界杀毒市场活了一把,“暗云Ⅲ”,Petya等等,一个比一个厉害,令人防不胜防,即使你染上了病毒也有可能完全不知情。
目前人们并没有养成很好的上网习惯,病毒预防的意识也很差,而且大多数用户更倾向于老旧版本的操作系统,以为旧的系统各方面都更加成熟,用起来也顺手,对于系统升级,维护方面有很强的抵触心理。

勒索病毒.jpg


这里OTPUB小编就跟大家分享4个平时生活中预防网络病毒的建议。
1、安装杀毒软件,这一点相信大多数的人都做到了这一点;在使用杀毒软件的时候,建议开始病毒库自动更新,保证杀毒软件可以最快的识别网络上的新型病毒,另外,建议每周至少一次对个人电脑进行一些全盘病毒扫描,确保电脑没有隐藏的病毒。
2、使用基于客户端的防火墙或过滤措施,以增强计算机对黑客和恶意代码的攻击 的免疫力。或者在一些安全网站中,可对自己的计算机做病毒扫描,察看它是否存在安全漏洞与病毒。如果你经常在线,这一点很有必要,因为如果你的系统没有加设有效防护,你的个人资料很有可能会被他人窃取。
3、在使用外接设备(例如U盘,光盘,移动硬盘灯)时,先对其进行扫描,以防万一。
4、不安装来历不明的软件,下载软件要到官方指定的站点下载,切不可贪图省事去一些未知网站,以防下载的软件里面包含电脑病毒。
想要了解更多关于网络安全的知识,敬请关注7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您详解安全管理的未来发展趋势。
点击此处预约直播>>>
或扫描下方二维码预约

论坛.jpg


​支付宝为什么很少被网络黑客攻击

OT学习平台 发表了文章 • 0 个评论 • 659 次浏览 • 2017-07-20 17:26 • 来自相关话题

现在越来越多的黑客行为都趋向以盈利作为目标,黑客通过攻击企业内部系统或网站来达到其目的,近期最受关注的莫过于5月份Wannacry勒索病毒事件,全球超过100个国家受到病毒的影响。那么,作为中国目前最大的第三方支付平台的支付宝为什么从没有传出过被黑的新闻?

在2008年,支付宝乃至阿里巴巴整个平台的网络进行了大规模的升级维护,不夸张的说,其安全级别甚至可以和五角大楼相比,这并非说黑客无法攻破,而是黑进去以后的数据连锁机制无人可破,支付宝的数据保护有自启动和认为启动两种,触发后的结果就是整个支付宝平台陷入瘫痪,等工程师修复漏洞后重启才可继续使用,而平台内的资金在这期间只是一串数字,在这期间无法转入转出分毫,也就是说,黑了你也取不走。全世界的大型银行的网络终端各有不同,唯独这个闭锁机制大同小异。
近年来,黑客行为变得似乎更加猖獗,每年都会有数起大型企业遭到入侵事件,甚至连世界知名的杀毒软件厂商卡巴斯基都惨遭毒手,正应了那句老话“玩鹰的被鹰啄了眼”;2015年6月,该公司声称探测到一次针对其系统隐蔽性极高的黑客攻击,实施这次攻击的黑客很可能是策划 2011 年 Duqu 木马的幕后黑手。就在2015年,美国还有 CVS 等连锁药店、大型电信运营商 、婚外情交友网站、大型医保企业、美国官方各部门等均被黑。国内企业也不例外甚至更严重,网站被黑的原因很大一部分是属于经济原因,但并非所有攻击都是因为经济缘故。
黑客行为一般分为以下四种:
一、受雇于他人,商业竞争对手恶意竞争,雇佣黑客攻击同行,敲诈勒索,盗取同行银行账户信息以获取既得利益;
二、恶作剧型,这一类的黑客行为大多是新手黑客,为了满足自己的虚荣心,搜索肉鸡,攻击一个网站,挂上网页木马来试验自己的水平。
三、打击报复型,在互联网行业,因相关服务不到位引起的商业纠纷陷入解决的僵局之后就容易出现黑客攻击报复的行为。
四、窃取资料型,主要是针对拥有付费产品信息的网站。
至于说黑客攻击支付宝这种巨头级企业的可能性则微乎其微,举个很简单的例子,盗贼如果想去某个村民家里偷只羊或许很容易,但是即使再多的盗贼也很难攻打下一个城市。因而一般来讲除了受雇于竞争对手的成建制黑客外很少有人敢对巨头企业下手。
在这一波一波勒索病毒爆发的浪潮之中,安全威胁是每个人头顶上挥之不去的阴云。数字时代为人类带来便利的同时,安全是永恒的话题。其实,对勒索软件的防范应该变被动为主动。Splunk 主动追踪安全威胁,显著增强追踪网络攻击者的能力。精彩尽在 7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您详解安全管理的未来发展趋势。
点击此处预约直播>>> 查看全部
现在越来越多的黑客行为都趋向以盈利作为目标,黑客通过攻击企业内部系统或网站来达到其目的,近期最受关注的莫过于5月份Wannacry勒索病毒事件,全球超过100个国家受到病毒的影响。那么,作为中国目前最大的第三方支付平台的支付宝为什么从没有传出过被黑的新闻?

在2008年,支付宝乃至阿里巴巴整个平台的网络进行了大规模的升级维护,不夸张的说,其安全级别甚至可以和五角大楼相比,这并非说黑客无法攻破,而是黑进去以后的数据连锁机制无人可破,支付宝的数据保护有自启动和认为启动两种,触发后的结果就是整个支付宝平台陷入瘫痪,等工程师修复漏洞后重启才可继续使用,而平台内的资金在这期间只是一串数字,在这期间无法转入转出分毫,也就是说,黑了你也取不走。全世界的大型银行的网络终端各有不同,唯独这个闭锁机制大同小异。
近年来,黑客行为变得似乎更加猖獗,每年都会有数起大型企业遭到入侵事件,甚至连世界知名的杀毒软件厂商卡巴斯基都惨遭毒手,正应了那句老话“玩鹰的被鹰啄了眼”;2015年6月,该公司声称探测到一次针对其系统隐蔽性极高的黑客攻击,实施这次攻击的黑客很可能是策划 2011 年 Duqu 木马的幕后黑手。就在2015年,美国还有 CVS 等连锁药店、大型电信运营商 、婚外情交友网站、大型医保企业、美国官方各部门等均被黑。国内企业也不例外甚至更严重,网站被黑的原因很大一部分是属于经济原因,但并非所有攻击都是因为经济缘故。
黑客行为一般分为以下四种:
一、受雇于他人,商业竞争对手恶意竞争,雇佣黑客攻击同行,敲诈勒索,盗取同行银行账户信息以获取既得利益;
二、恶作剧型,这一类的黑客行为大多是新手黑客,为了满足自己的虚荣心,搜索肉鸡,攻击一个网站,挂上网页木马来试验自己的水平。
三、打击报复型,在互联网行业,因相关服务不到位引起的商业纠纷陷入解决的僵局之后就容易出现黑客攻击报复的行为。
四、窃取资料型,主要是针对拥有付费产品信息的网站。
至于说黑客攻击支付宝这种巨头级企业的可能性则微乎其微,举个很简单的例子,盗贼如果想去某个村民家里偷只羊或许很容易,但是即使再多的盗贼也很难攻打下一个城市。因而一般来讲除了受雇于竞争对手的成建制黑客外很少有人敢对巨头企业下手。
在这一波一波勒索病毒爆发的浪潮之中,安全威胁是每个人头顶上挥之不去的阴云。数字时代为人类带来便利的同时,安全是永恒的话题。其实,对勒索软件的防范应该变被动为主动。Splunk 主动追踪安全威胁,显著增强追踪网络攻击者的能力。精彩尽在 7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您详解安全管理的未来发展趋势。
点击此处预约直播>>>

DevOps详解

OS小编 发表了文章 • 0 个评论 • 520 次浏览 • 2017-07-18 00:04 • 来自相关话题

最近我阅读了很多有关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​  

目录






1. 简介​

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。




开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。
 
1.1 管理信条
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论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,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。
 
1.2 一个典型的IT组织
在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:




主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:




此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)
 
1.3 运维人员测挫败感
接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:




来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services 
 
生产团队有将近一半(47%)的时间花在了与部署有关的工作中:
执行实际的部署工作,或修复与部署工作有关的问题
这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:
通过自动化部署将目前这种手工任务所需的时间减少31%。通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。
 
1.4 基础架构自动化
在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。




这些统计告诉我们:
只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。如需手工运行55条命令,成功部署的概率将跌至22%。如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!
成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:




(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:
Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。Flickr每天部署10次。Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。
他们这种做法秘密何在?
 
 
1.5 DevOps:仅此一次,一颗神奇的银子弹
他们的秘密很简单:将敏捷扩展至生产端:
 




喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论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,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。
那么核心原则到底是什么?




下文将介绍最重要的三大基本原则。
 
2. 基础架构即代码
人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。
 
2.1 概述
以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:
 




上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。
 
2.2 DevOps工具链
DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:
编码:代码开发和审阅,版本控制工具、代码合并工具构建:持续集成工具、构建状态统计工具测试:通过测试和结果确定绩效的工具打包:成品仓库、应用程序部署前暂存发布:变更管理、发布审批、发布自动化配置:基础架构配置和部署,基础架构即代码工具监视:应用程序性能监视、最终用户体验
虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。
 
基础架构组件的版本控制、持续集成和自动化测试
 
基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。
 
 
2.3 收益
DevOps的收益有很多,包括但不限于:
可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。
最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。
生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……恢复时间:一键点击即可恢复生产环境,就是这么简单。确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。
这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。
 
 
3. 持续交付
 
持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:
部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。




但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:
从实践中学习自动化更频繁的部署
 
3.1 从实践中学习
 
持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:




 
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论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,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。

那么核心原则到底是什么?

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。

2.1 概述

以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:

编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。

2.3 收益

DevOps的收益有很多,包括但不限于:

可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。

生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间!:一键点击即可恢复生产环境,就是这么简单。
确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。

3. 持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

从实践中学习
自动化
更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化
自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。
 
 
3.3 更频繁的部署
DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:
首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。




那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。
 
3.4 持续交付的前提需求
在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:
对软件组件的开发和平台的供应和设置进行持续集成。TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。软件的持续审计 - 例如使用Sonar。在生产级环境实现功能测试的自动化。更强大的非功能测试自动化(性能、可用性等)。独立于目标环境的自动化打包和部署。
另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。
 
 
3.5 零停机部署
 
“零停机部署(ZDD)可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时,可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看,这应该是最佳部署方式,因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术:
功能开关(Feature Flipping)摸黑启动(Dark launch)蓝/绿部署(Blue/Green Deployment)金丝雀发布(Canari release)
 
功能开关
功能开关可供我们在软件运行过程中启用/禁用相应的功能。这种技术其实非常容易理解和使用:为生产版本提供一个能彻底禁用某项功能的配置,并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说,若要将某个应用程序内的一个功能全局禁用或激活:
if Feature.isEnabled('new_awesome_feature')
# Do something new, cool and awesome
else
# Do old, same as always stuff
end或者如果要真对具体用户实现类似目的:

if Feature.isEnabled('new_awesome_feature', current_user)
# Do something new, cool and awesome
else
# Do old, same as always stuff
end 摸黑启动
摸黑启动的目的在于通过生产环境进行负载模拟!

在测试环境中,通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试,就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载,而是可以实际部署这样的功能,然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段,借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务,并且希望模拟所有用户同时输入文字,向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程,通过该进程将输入的搜索关键字发送给新增的自动补全服务,并自动发送多次。

就算新增的Web服务彻底崩溃了,也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了,我们至少还可以对该服务进行优化和完善,直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。
 
蓝/绿部署
蓝/绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后,可以修改负载均衡器的配置,以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收,用于构建下下一 查看全部
最近我阅读了很多有关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​  


目录


mulu.png


1. 简介​


DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。
woc.png

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。
 
1.1 管理信条
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论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,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。
 
1.2 一个典型的IT组织
在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:
devopsharch.png

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:
wofpeople.png

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)
 
1.3 运维人员测挫败感
接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:
sfd.png

来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services 
 
生产团队有将近一半(47%)的时间花在了与部署有关的工作中:
  • 执行实际的部署工作,或修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:
  1. 通过自动化部署将目前这种手工任务所需的时间减少31%。
  2. 通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

 
1.4 基础架构自动化
在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。
gl.png

这些统计告诉我们:
  • 只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
  • 如需手工运行55条命令,成功部署的概率将跌至22%。
  • 如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:
howmuch.png

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:
  • Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
  • Flickr每天部署10次。
  • Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?
 
 
1.5 DevOps:仅此一次,一颗神奇的银子弹
他们的秘密很简单:将敏捷扩展至生产端:
 
devops.png

喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论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,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。
那么核心原则到底是什么?
icc.png

下文将介绍最重要的三大基本原则。
 
2. 基础架构即代码
人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。
 
2.1 概述
以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:
 
asc.png

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。
 
2.2 DevOps工具链
DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:
  • 编码:代码开发和审阅,版本控制工具、代码合并工具
  • 构建:持续集成工具、构建状态统计工具
  • 测试:通过测试和结果确定绩效的工具
  • 打包:成品仓库、应用程序部署前暂存
  • 发布:变更管理、发布审批、发布自动化
  • 配置:基础架构配置和部署,基础架构即代码工具
  • 监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。
 
基础架构组件的版本控制、持续集成和自动化测试
 
基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成
 
 
2.3 收益
DevOps的收益有很多,包括但不限于:
  • 可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。
  • 生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
  • 恢复时间:一键点击即可恢复生产环境,就是这么简单。
  • 确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
  • 维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
  • 让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。
 
 
3. 持续交付
 
持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:
  • 部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
  • 部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
  • 部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

ttr.png

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:
  • 从实践中学习
  • 自动化
  • 更频繁的部署

 
3.1 从实践中学习
 
持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:
idmcc.png

 
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论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,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。

那么核心原则到底是什么?

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。

2.1 概述

以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:

编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。

2.3 收益

DevOps的收益有很多,包括但不限于:

可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。

生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间!:一键点击即可恢复生产环境,就是这么简单。
确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。

3. 持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

从实践中学习
自动化
更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化
自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。
 
 
3.3 更频繁的部署
DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:
  • 首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)
  • 第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。
  • 第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。

change.png

那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。
 
3.4 持续交付的前提需求
在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:
  • 对软件组件的开发和平台的供应和设置进行持续集成。
  • TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。
  • 代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。
  • 软件的持续审计 - 例如使用Sonar。
  • 在生产级环境实现功能测试的自动化。
  • 更强大的非功能测试自动化(性能、可用性等)。
  • 独立于目标环境的自动化打包和部署。

另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。
 
 
3.5 零停机部署
 
“零停机部署(ZDD)可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时,可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看,这应该是最佳部署方式,因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术:
  • 功能开关(Feature Flipping)
  • 摸黑启动(Dark launch)
  • 蓝/绿部署(Blue/Green Deployment)
  • 金丝雀发布(Canari release)

 
功能开关
功能开关可供我们在软件运行过程中启用/禁用相应的功能。这种技术其实非常容易理解和使用:为生产版本提供一个能彻底禁用某项功能的配置,并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说,若要将某个应用程序内的一个功能全局禁用或激活:
if Feature.isEnabled('new_awesome_feature')
# Do something new, cool and awesome
else
# Do old, same as always stuff
end
或者如果要真对具体用户实现类似目的:

if Feature.isEnabled('new_awesome_feature', current_user)
# Do something new, cool and awesome
else
# Do old, same as always stuff
end
摸黑启动
摸黑启动的目的在于通过生产环境进行负载模拟!

在测试环境中,通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试,就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载,而是可以实际部署这样的功能,然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段,借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务,并且希望模拟所有用户同时输入文字,向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程,通过该进程将输入的搜索关键字发送给新增的自动补全服务,并自动发送多次。

就算新增的Web服务彻底崩溃了,也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了,我们至少还可以对该服务进行优化和完善,直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。
 
蓝/绿部署
蓝/绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后,可以修改负载均衡器的配置,以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收,用于构建下下一