DevOps如何解决技术债务挑战?
许多组织在迁移到云期间发现了大量的技术债务。但是什么是技术债务呢?DevOps如何帮助我们去解决技术债务呢?在这篇文章中,我们将讨论使用DevOps将您的技术债务负担减少的方式!
什么是技术债务?
技术债务是指在整个应用程序生命周期内做出的次优技术决策的累积。最终,改变事物变得越来越困难,使IT计划陷入停顿。
例如,应用程序中不良的状态管理可能会使水平缩放策略难以实施。在执行您真正想做的事情(横向扩展应用程序,以便应对日益增长的流量)之前,您需要重新编写代码的状态管理部分。“先做需要做的事,然后再做想做的事”的工作就是技术债务。
值得指出的是,技术债务不仅会发生在开发中,还可能发生在运营中。例如:仍在运行不再受支持的过时的操作系统(Windows Server 2008或Ubuntu 11.04)。不保持服务器的修补程序更新和最新状态,会使您容易受到网络攻击和勒索软件的攻击。这些都是技术债务。
为什么会存在技术债务?
马丁·福勒(Martin Fowler)的技术债务象限指出,有时技术债务是无意的。您不知道的内容,但是现在您知道了,因此可以对其进行修复。
谨慎,刻意的技术债务是精益创业公司 Eric Ries的“构建-度量-学习”周期的核心。有时,了解您是否拥有可行产品的唯一方法是发布产品并将其掌握在客户手中。这可能意味着您“偷工减料”,从而招致技术债务。
DevOps如何解决技术债务挑战?
1.创建DevOps产品团队
DevOps的主要宗旨之一是创建小型,多学科的团队(即Dev + Ops),他们拥有产品或服务从“开始到结束”的整个生命周期。由于这些团队(包括他们的产品经理)每天都会感受到技术债务的影响,因此他们极有动力偿还技术债务,以使生活更轻松。
简单的事情可以帮助团队解决技术难题
第一步是评估和跟踪产品中的技术债务水平。
您可以通过将工作项(例如,在Jira,Azure DevOps或Github中)标记为“ TechDebt”来实现。接下来,您需要精简每个Sprint的一部分以处理技术债务项目。我们建议20%是一个不错的起点。
然后了解当前的技术债务水平。如果技术债务过多(不可接受的水平),则在下一个冲刺中优先考虑更多的解决债务工作。继续努力直到您的团队对技术债务不会阻碍实现您的产品目标感到满意为止。
最后,尽量避免 在新产品开发中造成 更多技术负担。使用技术债务象限评估设计选择并最大程度地减少新债务。
2. 使用DevOps自动化偿还技术债务
DevOps方法固有的特点是大量使用自动化。前面讨论的许多平台都可以使用自动化来构建和管理。而且,所提供的服务平台通常是供产品团队使用的自动化工具链。
但是DevOps自动化如何帮助偿还技术债务呢?
让我们进行环境管理,并考虑基础架构即代码和配置即代码如何可以帮助偿还技术债务,同时又避免了未来的债务。
不一致的环境是几乎每个人都会经历的技术债务的普遍形式。当您的应用程序在Dev中工作而在Pre-Production中不工作时,或更糟糕的是在Production中不工作时,根本原因通常是不一致的。这可以在操作系统配置,应用程序依赖性,应用程序所依赖的众多配置设置或组成该应用程序的不同服务之间的通信中找到。您花费在解决此类问题上的时间的成本就是技术债务。
基础架构即代码和配置即代码使您能够准确表达您想要的环境。然后,借助Terraform和Puppet等工具的强大功能,您可以声明在该环境的每个实例始终如一地“做到这一点”。容器化将其提升到一个新的水平。
“As-code”自动化也有另一个好处。在像GitHub这样的存储库中将DevOps自动化作为代码保存,而不是在冗长的Word文档或Visio图表中描述配置设置,可以使迭代和改进变得更加简单容易。人们可以通过搜索轻松发现代码,通过拉取请求甚至是派生代码提交建议的更改,对其进行修改和扩展以满足他们的需求。这种迭代能力意味着自动化代码不太可能“过时”,从而避免了另一种形式的技术债务。
3. 使用容器简化应用程序的部署和管理
什么是容器?它们如何帮助您偿还技术债务?
简而言之,容器使您可以将应用程序,应用程序的配置和操作系统相关性包含在一个轻量级的捆绑包中,该捆绑包更易于部署和配置。
与前面讨论的环境管理自动化示例一样,容器的可移植性简化了一切。诸如Kubernetes之类的容器编排工具甚至走得更远,可以实现生产中容器生命周期的自动化,从而使DevOps团队可以将精力集中于更高价值的任务(例如重新架构应用程序以减少技术债务)。
构建新的云原生应用程序的组织通常使用容器以较低的总拥有成本(TCO)来提高灵活性和可伸缩性。每个微服务都很小,具有清晰的边界上下文,并且由一个长期存在的团队进行管理。因此,技术债务更容易发现和修复。每个人的双赢方案。
4. 使用DevOps构建以API为中心的模型
上面讨论的微服务模型是一种实现以 API为中心的应用程序策略的方法。著名的杰夫·贝佐斯(Jeff Bezos)挑战了他的团队,要求他们仅使用API 在系统之间进行通信。
您的组织可能不太严格。尽管如此,鼓励团队使用定义明确的版本接口来构建和使用API是减少技术负担的好方法。通常,技术债务是由不同的系统以其他团队无法预期的方式访问服务和数据引起的。例如,TeamA直接从TeamB创建和管理的表中读取数据。如果TeamB更改该表的架构以满足他们的需求,则由于这种隐藏的依赖关系,他们可能会无意间破坏TeamA的应用程序 。
API使这些接口更加可见,并且不那么脆弱。每个产品都需要遵循已发布的API,并具有清晰的未来路线图,理想情况下应支持“ 语义版本控制 ”。如果在以后的某个阶段他们需要对API规范进行“重大更改”,则可以发布API的新主要版本,并在预定的支持期限内支持“旧” API。所有这些加在一起,减少了脆弱性=减少了技术债务。
DevOps模式和实践,例如使用CI / CD代码管道来构建,测试,打包和部署应用程序,使团队可以更快地移动,风险和技术债务更少。
代码管道还提供了应用程序代码的端到端可追溯性-从用户案例到代码提交再到发布的程序包。这样可以更轻松地管理技术债务。如果您已经按照前面的讨论跟踪并标记了技术债务,则可以看到它对实时系统和客户的影响。这有助于得出明确的,由客户驱动的优先事项,以将技术债务偿还工作重点放在那里。
文章转载自公众号:DevOps云学堂