持续DevOps文档:是必需的

日期:2016-2-10作者:Chris Riley翻译:崔婧雯来源:TechTarget中国 英文

DevOps   

【TechTarget中国原创】

现代软件交付完全是繁文冗节,对吗?不完全正确。文档和管控的流程仍旧是防止企业陷入困境,保证员工不丢掉工作的有效方式,让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。DevOps文档也不例外:它正在改革。

如果我们意识到过去IT企业是如何记录基础架构的,那么结论就是文档已经不完整很久了。文档上花费了大量时间创建永远也不会使用的信息。完成文档的核心动力是满足检查条件,而不是给团队带来实际受益。这里的问题是信息是发散的。文档以瀑布方式创建,很少更新,很容易出错并且缺少一致性。有时候团队太忙没时间完成整个文档,以致一起被废弃了。

但是,当需要解决问题,以及加速恢复时间时,文档是了解配置是什么以及哪里出错的唯一选择。因此,当文档成为阻碍现代开发速度的原因时,这并不是合理的借口。

在DevOps发布链里,不能指望手动写文档。很多人认为文档应该随之消失。但实际上,文档应该大幅加强才对。现代开发里,文档不但没有消失,而且其生成和目标都发生了本质的变化。

实际上,文档的生成很透明,以致于其看上去像消失了一样。真正的DevOps实践会花专门时间在实时收集应用和日志数据。它们将这些信息存储到智能日志分析平台,基于这些信息之上构建神奇的报警系统,持续跟踪正在发生的事情并且作出响应。但是他们没有意识到的是同时,他们已经构建出了自动化的文档系统。

DevOps文档的来源是:

1.代码

2.配置管理脚本

3.应用性能日志

3.基础架构日志

5.报警工具和警报

6.组件监控

可能一开始使用这些系统并不是为了写文档,但这正是DevOps流程真实发生的情况:

通过使用流行的设计架构模型视图控制器和自动化的文档创建系统,合适的应用程序架构本身就可以生成有质量的文档。

配置脚本,比如Puppet和Chef是文档服务器。脚本能够提供关于生产环境里的所有基础架构如何搭建的清晰视图。

应用性能管理和服务器日志成为应用和基础架构的历史视图。

报警工具成为所有失败事件以及如何组织响应的历史记录。

组件监控工具展示使用了哪些组件, 以及是否什么时候有相关更新或者失败。

所有这些工具和流程替代了手动创建文档的需求,并且,它们一起构成了环境的完整文档。有时候称之为持续文档。它们比手动文档有高得多的覆盖率。它看上去可能不是带着很多截屏的大型Word文档,但是它们的价值是一样的。

但是,持续DevOps文档必须使用合适的引入方式和恰当的计划才能落地。如果你没有决定如何消费这些信息,那么其价值会快速消散。

它的好处比想象的更大。对于团队的新成员而言,这是培训他们的轻松方式。只需要使用这些工具一周,比起直接的课堂式讲授,团队的新成员能够更为清楚地知道系统是如何搭建的。它还在系统出错时避免不得不找到出问题领域的专家,因为无需特别去抓取某些信息,所有信息都已经在那里了。比传统IT里能想象的还要更大的覆盖率。DevOps文档并没有消失。该领域的变革极大地改进了使用文档的方式。现在,文档的生成是自动化的,其使用是成熟的,而且更加频繁,并且它是源于操作的,而不是被迫响应生成的。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

SOA实施>更多

  • 持续DevOps文档:是必需的

    文档和管控的流程仍旧是防止企业陷入困境,保证员工不丢掉工作的有效方式,让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。

  • 避开软件容器:如何探索DevOps

    Bert Jan Schrijver,荷兰JPoint Java软件工匠,也是JavaOne大会的演讲者,他回答了SearchSoftwareQuality的有关DevOps的问题,并且回答了为什么有时应该忽略传统习惯。

  • DevOps和敏捷相结合 改进软件质量

    DevOps实际上是打破了开发人员和运维人员之间的壁垒。在运维团队,你所考虑的方面可能与开发团队不同。但如果我们能更加了解相互的工作,将会更为深入得理解所需的工具和设备。

  • AppDynamics引入应用集成平台

    AppDynamics的微服务架构应用集成平台(AIP)旨在对跨不同应用环境的应用进行统一监控,此前这一过程需要各种应用及架构相关的管理工具才能做到。

相关推荐

  • 对于orchestration而言 ALM和DevOps至关重要

    为了确保开发和运营能够持续同步演进,开发者需要理解DevOps与orchestration之间的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

  • 开发运维一体化(DevOps):协作是成功的保障

    如今的IT部门存在一个矛盾:敏捷开发者希望可以快速部署常规软件,而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标

  • 中国市场DevOps应用趋势分析

    为了解决开发人员与运维之间的协作问题,从而提升工作效率,DevOps方法论应运而生。几年的发展,DevOps现在国内市场的应用情况如何?如何才能取得DevOps实施的成功?

  • 避开软件容器:如何探索DevOps

    Bert Jan Schrijver,荷兰JPoint Java软件工匠,也是JavaOne大会的演讲者,他回答了SearchSoftwareQuality的有关DevOps的问题,并且回答了为什么有时应该忽略传统习惯。

技术手册>更多

  • 面向服务架构SOA与相关技术

    面向服务的体系结构(service-oriented architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 

    这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

  • UDDI(统一描述发现和集成)

    UDDI统一描述、发现和集成协议,是为解决Web服务的发布和发现问题而制订的新一代基于Internet的电子商务技术标准。全称Universal Description, Discovery and Integration,它包含一组基于Web的、分布式的Web服务信息注册中心的实现标准,以及一组使企业能将自己提供的Web服务注册到该中心的实现标准。UDDI利用SOAP消息来查找和注册Web服务。并为应用程序提供了一系列接口来访问注册中心。

    UDDI(统一描述发现和集成) 提供一种发布和查找服务描述的方法。UDDI数据实体提供对定义业务和服务信息的支持。WSDL中定义的服务描述信息是UDDI注册中心信息的补充。

  • BPEL 2.0服务契约手册

    本技术手册旨在探讨如何为封装WS-BPEL流程逻辑所需的Web服务设计WSDL定义。因为SOA提倡用“契约优先”的方式来设计服务,所以理解由WS-BPEL引发的这种独特服务契约设计理念,是成功构建有效流程和服务的关键因素。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算