首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何理解DevOps

引言

DevOps是一种重要的软件开发模式;

我所在的团队正在进行DevOps转型;

DevOps极大地提升了开发效率;

本文介绍了我对DevOps的理解;

什么是DevOps

DevOps是一种软件开发人员(Research and Dev,RD)和IT运维运营技术人员(Ops)和质量检测(QA)之间沟通合作的模式;

DevOps的根本目的是快速频繁的、小步的、自动化便捷的监控和审计的、云端和虚拟化的、可视化的部署,满足“每天部署10次”或者“快速解决bug并上线”的要求;

DevOps是敏捷开发、持续交付的基础;

DevOps模式和传统的瀑布模型相对应;

我们需要维护什么?

以我所在的团队为例,我们需要维护的内容如下:

需要维护的环境分为:开发环境,测试环境,准生产环境,生产环境;

每个环境包含若干个scope,每个scope都是整个系统的一部分,由不同的团队进行开发;

使用microsoft微服务架构,每个scope中都有若干service,每个service之间可能还存在相互依赖关系;

每个service都需要若干resource,这些resource包括但不限于:

RabbitMQ;

Service Fabric;

IoTHub;

EventHub;

ELK;

Consule;

KeyVault;

MongoDB;

Postgresql;

Cassandra;

Storm;

Redis;

如果没有DevOps,我们怎样工作?

没有流水线Pipeline:

开发过程变得非常痛苦,会经常忘记对代码进行单元测试和集成测试;

开发完成的服务,打包后不知道放在何处,别人需要引用时很不方便;

代码质量得不到保证,很多代码没有经过“单元测试覆盖率检测”和“代码重复率检测”,代码可维护性变差;

随着开发的深入进行,开发人员的主要精力不在是编写新的代码,而是处理bug和维护旧的代码,使开发效率逐渐降低;

没有自动化环境部署:

在开发者完成一个微服务的开发后,不知道将自己开发的服务部署到什么环境上去测试;

开发者在测试自己的代码时,会时常发现所依赖的资源没有准备好,比如测试环境缺少MongoDB等资源;

运维人员不能显式的看到自己维护了多少资源,每种资源都在被哪些环境、哪些service引用;

运维人员不能显式的看到资源的使用情况及使用量;

经理不能有效的进行成本控制;

没有自动化监控系统:

运维人员不能在机器、硬件、软件出现故障时得到及时的警告,导致机器挂掉了都还不知道;

不能灵活调配各种资源的使用,导致某些资源极度紧缺、某些资源却有富余;

手动,而不是自动:

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

为什么要有DevOps

不知道目前发布、部署的进展情况;

没有一套明确的发布、部署流程,急上线时容易出问题,出了问题也没有预案来解决;

自动化程度不够;

DevOps工具链

编码:代码开发和审阅,版本控制工具、代码合并工具;

构建:持续集成工具、构建状态统计工具;

测试:通过测试和结果确定绩效的工具;

打包:成品仓库、应用程序部署前暂存;

发布:变更管理、发布审批、发布自动化;

配置:基础架构配置和部署,基础架构即代码工具;

监视:应用程序性能监视、最终用户体验;

DevOps的多维度目标

团队维度:拟合开发和运维的鸿沟,支持位于全球多个地点的、包含外包人员的、混合开发/测试/基础设施的团队;

技术维度:拟合多类型的分布式的硬件平台和上面部署的多种应用、多种需求的鸿沟;

需求维度:平衡软件开发过程中对软件用户需求变化、追求稳定性、追求开发效率、降低check-in风险这几个目标;

市场维度:解决软件迭代慢和较高的用户需求的矛盾;

终极目标:从时间和空间两个维度,合理统筹并高效使用现有资源,实现组织目标,最大限度满足用户需求;

DevOps需要遵循的基本原则

以人为本,一切工具都是为人服务;

需求细分,及时开发,及时验证;

减少开发的分支,尽量在主干上开发,避免合并分支造成的开销和时间浪费;另外,分支太多的时候不可能做到持续集成;

减少代码积压,代码积压越多、越多的需求和开发成果得不到验证、效率就越低、下次部署的风险就越大;

代码和配置相分离,尽量降低他们在逻辑或者物理上的耦合;

尽早生成二进制包,而不是使用源代码,并确保二进制包不被篡改;

二进制包应当和环境无关;

确保部署流程是幂等的;

对生产和测试环境的修改只能由程序,而不是人完成;

环境管理

环境必须遵循:快速部署和响应(使用docker或者其他虚拟化技术能够更容易做到这一点),可恢复,可支持,可审计;

环境配置项目:

操作系统和配置;

中间件和软件栈及配置:数据库,消息系统,队列;

基础设施软件:代码管理,目录服务,监控;

外部集成:外部系统和服务;

网络:路由,防火墙,交换机,DNS;

团队:开发团队和infra团队之间的协调分工;

自动化的环境部署;

测试环境应当和生产环境尽量一致;

环境的配置文件也应当进行版本控制;

监控

监控的内容:

硬件,物理设备,路由器,代理;

操作系统;

中间件;

应用程序;

日志;

如何监控:

清晰的信息展示;

及时地告警;

可视化的状态呈现;

常用DevOps利器

Jenkins:开源的持续集成工具;

SonarQube:开源的代码质量管理系统;

Puppet:开源的软件自动化配置和部署工具;

Docker:让应用程序布署在软件容器下的工作可以自动化进行;

总结:DevOps到底是什么?

高效的流水线开发/测试/上线;

自动化的环境部署和管理;

良好和及时的监控/告警/可视化/反馈/日志;

开发团队、运维团队、用户之间良好的沟通协作,快速解决问题的能力;

完整的文档;

任一模块的幂等和可恢复;

良好的审计和评估,良好的成本管理;

整个系统稳定且灵活,高度自动化;

总而言之,DevOps的核心只有三个词:高效、自动、监控;

参考

分享&在看

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20220224A0C26W00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券