持续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与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

  • SOA与Web服务管理

    不管是服务的质量或是可靠性或是可获得性,所有这些能力服务都必须具有,他们必须以适当的方式工作。可能一个供应商提出了一个SOA管理技术,而且是如此地优于其他的技术以致于其实际上成为了事实上的标准。但是更可能的是相同的竞争压力驱使供应商试图合并,而唯一的SOA管理产品最终迫使市场在内部协作性上妥协,如果不能获得一个实际上的基于标准的方法。

  • 轻量型框架资源手册

    在EJB技术之前,我们开发一个复杂Java企业应用系统时,会在代码设计中充满各种底层技术的味道,EJB则将很多底层技术:缓存、池、安全以及事务封装在特别的EJB服务器中,解脱了开发者的工作。但是我们还是很有必要思考一下:我们开发者到底需要什么样的技术?这样才能在瞬间变化的发展潮流中坚持自己观点,而不是人云亦云,迷失方向。

  • 云应用性能管理和测试教程

    云里来雾里去的云计算讲了好多年,其实对于大众来讲对这个概念仍然是有些摸不着头绪。那么对于已经应用了云服务的企业而言,在实践中有哪些技巧可以参考或者有哪些经验可以分享呢?在这期技术手册中,我们将一起来关注云应用的可用性,如何进行云应用的监控,云服务中间件如何?同时我们将侧重于云应用性能管理以及云应用测试的内容。

TechTarget

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