文档章节

年度十佳 DevOps 博客文章(前篇)

OneAPM蓝海讯通
 OneAPM蓝海讯通
发布于 2016/02/25 12:00
字数 3697
阅读 58
收藏 2

如果说 15 年你还没有将 DevOps 真正应用起来,16 年再不实践也未免太落伍了。国内 ITOM 领军企业 OneAPM 工程师为您翻译整理了,2015 年十佳 DevOps 文章,究竟是不是深度好文,大家一起来看看吧!

本文译自 Hasan Yasar 的文章 the Top 10 Devops Posts of 2015 .

2015 年 8 月,DevOps 博客 推出了自己的平台。DevOps 博客针对越来越多采用 DevOps 的企业(自 2011 年来占比高达 26%),提供各种指南、实用建议和教程。根据近期研究,这些企业变更代码的速度比传统企业快 30 倍。尽管 DevOps 的优势显而易见,很多企业仍然不敢欣然采用,因为这不仅需要转变观念,还要改变文化和技术要求,后者对孤立的竖井式企业而言,是极大的挑战。考虑到这些障碍,CERT 研究人员的文章主要集中介绍 Amazon 和 Netflix 的 DevOps 成功案例,以及 Fabric、Ansible 和 Docker 等流行 DevOps 技术的教程。本文则介绍了 2015 年 10 篇最受欢迎的 DevOps 文章(倒序)。 年度十佳 DevOps 博客文章(前篇) 年度十佳 DevOps 博客文章(前篇)

10.迷失的 DevOps 指标

有人说 DevOps 是一种方法;也有人说 DevOps 是一种运动,一种哲学甚至一种策略。定义 DevOps 的方式有很多种,但对于其基本目标大家都已经达成共识:将开发和运维相结合,努力降低风险,减轻负担,缩短上市时间,同时提高运维意识。但早在 DevOps 这个术语流行起来之前,其发展就可以追溯到二十世纪七十年代早期兴起的工具自动化、文化转移和迭代开发模型领域(例如敏捷开发)。

社群推动了 DevOps 的发展,并将软件开发领域方方面面的理念注入了 DevOps,因此赋予了其强大的能量。但由于社群中未能形成集中的操作指南,因此也对 DevOps 的进步造成了阻碍。

通常,意图采用 DevOps 的企业会依照繁琐的运维手续和竖井式文化使用 DevOps。对于以“无 DevOps”为基础建立的企业(以及设立的员工预期),这一转型并不容易。此外,一旦某个团体决定尝试实施 DevOps(这通常是团体自身的挑战),就会面临“如何合理实施”这一问题。在 2015 年发布的十篇最受欢迎的文章中,Tim Palko在《迷失的 DevOps 指标》中探讨了这一问题。

下面是这篇文章的摘录:

对 DevOps 采用率的研究使用了“已采用”或“将采用”这些措辞,仿佛它们是企业季度目标的行项目。这是否表示他们已与 Flickr 的每日十大部署看齐,还是说他们只是使用了“采用”这一措辞的浅层含义,只是接受了自己的宿命,不会遵从 DevOps 哲学?考虑到 DevOps 具备的多种定义,“采用”一词的意义可能拥有同样数量甚至更多的变化形式。无论如何,DevOps 都羽翼未丰,它只是各种正负属性的连续统一体,甚至远未达到线性。

我并不打算立什么里程碑。在一些团队里,取得任何程度的 DevOps 成就都值得大餐一顿,以示庆祝。然而,要制定目标,只知道 DevOps 是一种文化和技术远远不够。另一种观点是,你采用 DevOps 的目标就是你需要 DevOps 达到的效果。换言之,家家有本难念的经,而 DevOps 给出的海量解决方案必然能够开启良好开端,帮助大家解决问题,即使只需要一两个解决方案。

DevOps 的发展似乎一切顺利,不依靠任何枯燥精简的标准和指标。尽管如此,如果我们一心改变却不对变化加以测量,就可能走上给流程镀金的无尽之路。结果可能是好的,但客户也在这样的文化变革中投入了真金白银,无论他们是否知情、是否希望知情甚至毫不知情。因此,必须对变化进行规划,并设立明确的目标和完成日期。

阅读原文 & 系统监控解决方案推荐

9.DevOps 技术:Vagrant

环境对等 (Environment parity) 是一种理想状态,执行代码时所在的各种环境等效运行。软件开发问题日益令人沮丧,很多难题悬而未决,缺少环境对等性就是其中一个问题。部署和开发经常是这个问题的受害者,稳定性、可预测性和工作效率都因此降低。如果达不到对等性,各环境就会以不同方式运行,这样,解决疑难问题就会变得棘手,协同也无从谈起。对于太多开发人员和运维人员来说,缺少对等性都是个负担。

在 DevOps 技术:Vagrant 这篇文章中,CERT 研究人员 Tim Palko 介绍了 Vagrant ,一种借助一个声明脚本和一个简单的命令行界面就可以为开发人员提供虚拟化配置环境的开发工具。Vagrant 对所有开发人员和工作使用相同的预配置(脚本型)环境,从而提高了开发和环境对等性。Vagrant 让应用程序开发周期过程中“机器工作不受人控制”这样的理由不再是理由。

下面是这篇文章的摘录:

运维团队的工作通常包括在各个部署环境(例如测试环境、模拟环境和运作环境)中实施全面的对等性。反之,开发团队则几乎全权负责配置开发机器。为了实现两组环境之间的完全对等,两个团队必须使用相同的语言和资源。  Chef 和 Puppet 工具都是专为运维人员而生,对忙碌的开发人员来说有些难以触及。每一种工具都有可观的学习曲线,但没有哪种工具确实完全地解决了对等问题:开发人员仍然需要将适当的生产目标平台虚拟化。这些额外工作都会导致可观的开销,而此时你只是想编写代码!

这时候,Vagrant 就派上用场了。Vagrant 是一款开发者工具,仅借助一个声明脚本和一个简单的命令行界面就可为使用运维工具的开发人员提供虚拟化的配置环境。Vagrant 剔除了支撑虚拟主机 (VM) 所需的繁重工作,还避免了配置或运行 Chef 服务器和 Chef 客户端。Vagrant 隐藏了所有这些工作,只给开发人员留下一个简单的脚本和一个名为 Vagrantfile 的无扩展名头文件,可在源码控制和代码中检查该文件。

阅读原文:https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345

8.DevOps 团队使用 ChatOps

一个项目团队中关键利益相关者(例如开发人员、业务分析师、项目经理和安全团队)之间的对话,以及他们的沟通平台都会对协作产生深刻影响。沟通工具不理想或不熟悉,会造成沟通不畅、徒劳无功甚至执行有误。另一方面,如果沟通工具集成了开发和运维基础架构,就能够缩短将商业价值交付给公司的时间。团队的沟通基础架构组织方式直接影响团队效率。

在 DevOps 团队使用 ChatOps 这篇文章中,CERT 研究人员 Todd Waits 首次引入了 ChatOps 这个概念, ChatOps 作为 DevOps 的分支,侧重于 DevOps 团队内部的沟通。ChatOps 空间主要包括团队内的沟通和协作工具:通知、聊天服务器、机器人、问题追踪系统等。

下面是这篇文章的摘录:

在近期的一篇博客文章 中,Eric Sigler 写到,ChatOps 这一术语源于 GitHub,主要是指对话驱动式开发。“将工具代入对话,使用经改良的聊天机器人来配合使用关键插件和脚本,团队就能自动运行任务并展开协作,工作表现更出色,费用更低,速度也更快,”Sigler 写道。

大多数团队都会在聊天服务器上开展一定程度的协作。聊天服务器可以作为大型开发团队的“城市广场”,有利于促进团队之间的凝聚力,为团队成员的所有活动提供一个空间,比如用大量 gif 图像 抒发情感,讨论实际问题的潜在解决方案等。我们希望所有团队成员都使用聊天服务器。在我们的团队中,为了避免一般聊天室的灌水聊天,我们也为每个项目创建专用聊天室,项目团队成员可以谈论项目的细节,不涉及其他团队。

聊天服务器不仅仅是简单的沟通媒介,它还可以智能化,先从开发基础架构向团队传递通知,然后执行命令并从团队返回基础架构。聊天服务器是通知中心,可以和开发基础架构快速互动。项目团队通过聊天服务器(以及其他渠道)接收关于其希望关注的所有构建状态的通知:构建失败、构建成功、超时等。

阅读原文 & 推荐「探讨如何将 DevOps 与 ChatOps 结合」的文章 当我们在谈论 DevOps,我们在谈论什么?

7.DevOps 容器安全性

基于容器的虚拟化平台给出了一种方法,可以在单独的实例上运行多个应用。容器技术可以为 DevOps 提供极大效益,包括可扩展性提升,资源利用率提高,弹性增强。尽管如此,除非从主机系统分离容器,否则可能存在安全问题。Chris Taschner 在 DevOps 的容器安全问题 这篇博客文章中说明了在分离前,管理员为何应当密切关注容器内所运行的应用程序的特权级别和访问主机系统的用户的特权级别。

容器现已成为 DevOps 的大热新技术。Docker 这家公司尤其已经成为容器技术的架构首选提供商。利用 Docker 平台,可以将应用程序连同其所有依赖项打包放进一个被称为图像的单元中。然后 Docker 就可以运行该图像的实例。每一个实例都留在一个容器中。

Docker 正在成为 DevOps 的代名词。如果您还不了解容器的优势,请听我慢慢道来。一个极小的容器中可以包含现成的图像、易于使用的公共资源库、图像版本控制以及 Docker 的应用程序本质。(更多信息请参见 devops.com 上的文章——使用 Docker 的三大原因)

就大小而言,容器也具备大量优势。和虚拟主机不同的是,容器不需要运行全面的操作系统,也不需要系统所有硬件的虚拟复本。只要操作系统和硬件信息足够使用,容器就能将其负责的应用运转起来。最终,容器可以比虚拟主机还小得多,这样主机系统运行的容器数量就会远多于其运行的虚拟主机数量。

阅读原文 & Docker 监控实战

6.DevOps 案例分析:Amazon AWS

经常阅读 DevOps 博客 的读者会发现,这个系列经常出现的主题 是:* DevOps 的本质是通过精心构建组织流程、沟通和工作流来巩固所需质量属性 。通过研究知名科技公司的软件工程/维护管理技术,DevOps 博客作者可以呈现真实的宝贵案例,得出大量软件工程方法及相关成果。这些案例也非常值得 DevOps 从业人员借鉴。在「DevOps 案例分析:Amazon AWS 」这篇文章中,C. Aaron Cois 分享了 Amazon 的 DevOps 使用经验。

下面是这篇文章的摘录:

Amazon 是当今最多产的科技公司之一。2006 年,Amazon 从一家在线零售商成功转型为科技巨头,并推出 Amazon Web Services (AWS),成为云服务领导者。AWS 是一项拥有广泛用户的按需定制型 IaaS (基础架构即服务)服务。对于 AWS,Amazon 承受了大量风险。通过开发首批大规模的公共云服务,Amazon 认识到,很多挑战都是未知的,许多解决方案也未经证实。要学习 Amazon 的成功经验,我们需要问出正确的问题。这项商业冒险活动存在固有风险,为了将风险降到最低,Amazon 采取了哪些措施?Amazon 工程师如何设计其流程以保证质量?

幸运的是,谷歌工程师 Steve Yegge(前 Amazon 工程师)意外公布了一份内部备忘录,其中概述了他对谷歌平台开发失败(以及 Amazon 取得成功)的感想,从而让世人对这些问题有了大致了解。这份备忘录(Yegge 特别允许可在网络上传播)概括地介绍了一项具体决策,该决策描述了首席执行官 Jeff Bezos 对我们现在称之为 DevOps 的基本原则的理解,以及他对互操作性、可用性、可靠性和安全性(笔者认为这些是 AWS 平台的主要质量属性)的奉献。

阅读原文

以上是 15 年年度十佳 DevOps 博客文章的第 6-10 名,有没有哪一篇抓住了您的眼球,让您有所收获呢?预知 1-5 名的文章,请期待「年度十佳 DevOps 博客文章(后篇)」。

Cloud Insight 集监控、管理、计算、协作、可视化于一身,帮助所有 IT 公司,减少在系统监控上的人力和时间成本投入,让运维工作更加高效、简单,已在阿里云云市场上线,云市场详情请戳

本文转自 OneAPM 官方博客

© 著作权归作者所有

OneAPM蓝海讯通
粉丝 94
博文 631
码字总数 1266889
作品 0
海淀
私信 提问
年度十佳 DevOps 博客文章(后篇)

如果说 15 年你还没有将 DevOps 真正应用起来,16 年再不实践也未免太落伍了。在上篇文章中我们了解到 15 年十佳 DevOps 博客文章的第 6-10 名,有没有哪一篇抓住了您的眼球,让您有所收获呢...

OneAPM蓝海讯通
2016/02/26
35
0
【干货合集】从菜鸟到老司机,20篇文章带你了解DevOps!

如今,虽然业内还并未对DevOps的定义达成共识。但是几乎每个行业机构和组织都制定了一套自己的DevOps实践。他们以为只要进行自动化、配置管理和敏捷开发,就算是真正意义上了解并实践了DevOp...

林一木
2018/05/14
0
0
数云荣获2016新网商年度十佳服务商

近期,由电商媒体《天下网商》主办、阿里巴巴合作支持的2016新网商峰会召开,与来会嘉宾共同探讨新零售的未来。《天下网商》从全渠道、内容营销、数据运营、全球化和科技应用等方面,以敏锐的...

玄学酱
2018/04/23
0
0
Fbric、Ansible、Docker、Chaos Monkey:DevOps工具的年中回顾

Fbric、Ansible、Docker、Chaos Monkey:DevOps工具的年中回顾 【编者按】近日,Cyber Engineering Solutions Group 技术经理 Hasan Yasar 在 SEI 攥文盘点了当下流行的 DevOps 思想和工具,...

OneAPM蓝海讯通
2015/08/10
78
0
2014 年度站内其他类型排行榜

翻译 评判标准:收藏+点赞+顶 2014 年含金量最高的十大翻译文章 博客 评判标准:收藏+点赞+评论? 2014 年含金量最高的 20 篇技术博客 PS:站内各个专题汇总新闻 1. 2014 年年度高手问答超级...

叶秀兰
2014/12/03
6
1

没有更多内容

加载失败,请刷新页面

加载更多

秒杀系统思路

业务分析 技术挑战 请求响应要快:无论成功失败,需要尽快返回给用户 架构设计   前端:静态化   站点层:限制请求数   服务层:乐观锁写缓存   数据库CAP:读写高可用,一致性,扩容...

雷开你的门
12分钟前
7
0
最全的教育行业大数据解决方案,个个针对痛点

大数据的悄然兴起也带动了教育行业的革新,移动教育、云课堂等的出现,使得教育行业再次成为了可以中长期保持高景气的行业。然而,初涉数据领域的教育行业同时也面临着相当大的难题,还需要更...

朕想上头条
16分钟前
5
0
预约模块设计分析

1.预约功能描述: 预约是小程序中常见的一种商品管理系统,商家可根据商品或服务的特性,灵活设置预约细节,为用户提供线上预约服务,如场地预约,商品预定等,实现高效经营。 预约场景: ...

鱼煎
19分钟前
4
0
阿里云日志服务构建网站实时分析大盘实战

场景分析 挖掘数据价值是当前企业级网站共同面临的问题。买买网是一个电商平台网站,每天拥有大量的用户访问和购买记录。为了引导用户直接消费,提升购买率和转化率,不同的用户类别需要推荐...

阿里云官方博客
20分钟前
2
0
TL665xF-EasyEVM开发板硬件处理器、NAND FLASH、RAM

广州创龙结合TI KeyStone系列多核架构TMS320C665x及Xilinx Artix-7系列FPGA设计的TL665xF-EasyEVM开发板是一款DSP+FPGA高速大数据采集处理平台,其底板采用沉金无铅工艺的6层板设计,适用于高...

Tronlong创龙
24分钟前
8
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部