初创公司中的DevOps。 神话还是现实

什么是DevOps? 这是一种思维方式和一种工作方式。 它混合了开发和运营团队承担的任务,以使应用程序交付更快,更有效。


在初创企业中适应这种新愿景并不像看起来那样简单。 这是为什么 ? 在DevOps中,我们可以陈述3种原理,所有DevOps模式都可以从中推导,这些原理是:

  1. 系统思考:它强调整个系统的性能,而不是特定的工作部门或部门的绩效。 重点关注由IT启用的所有业务价值流。 将该原则付诸实践的结果包括:永远不会将已知的缺陷传递给下游工作中心;永远不会允许局部优化造成整体性能下降;总会设法增加流程;总会寻求对系统有深刻的了解(根据Deming)。
  2. 放大反馈回路:这是关于创建从右到左的反馈回路。 几乎所有过程改进措施的目标都是缩短和放大反馈回路,以便可以连续进行必要的纠正。 该原则的结果包括了解和响应所有内部和外部客户,缩短和扩大所有反馈回路,以及在需要时嵌入知识。
  3. 持续实验和学习的文化:这是关于创建一种培养两件事的文化:持续实验,冒险和从失败中学习。 但是,我们需要理解重复和练习是精通的前提,因为我们同样需要它们。 实验和冒险是确保我们不断推动改进的动力,即使这意味着要比以往任何时候都更深入危险区域。 我们需要掌握一些技巧,这些技巧可以帮助我们在走得太远时退出危险区域。 该原则的结果包括分配时间改善日常工作,创建奖励团队冒险的仪式以及将错误引入系统以提高弹性。

对于一家初创企业来说,从这些原则中进行选择根本不是一件容易的事,它需要在短期内做出很多牺牲,才能在长期内取得良好的最终结果。


起点:

雇用DevOps不仅要招募人员来进行运营和开发,还需要整个组织的影响。 在Avito.ma中,雇用第一批DevOps的想法来自从数据中心迁移到云的决定(在我们的案例中是AWS),因此我们需要云上经验丰富的人员来管理我们的堆栈。

最初,此人首先使用内部工具在云中设置堆栈,该工具采用了正在运行的系统的描述,并有可能在所选的云平台中运行网站/服务/应用程序的堆栈。

从数据中心到云的迁移工具

之后,他使用zabbix进行了一些基本监控的设置,但问题是开发人员仍在按照相同的速度进行操作,因为云中的堆栈对他们没有任何改变,因此PM仍然像对待产品一样没有改变。 这不是DevOps。

随着业务的增长,需要部署新功能,我们开始遇到问题,错误不断增加,性能下降,将任何东西推向生产的时间都在增加,部署是手动的,我们有很多回滚,每个人在抱怨:开发人员,客户服务,项目经理,推销员,经理……我们确实处于地狱的陷阱,有人说“我们去生产”对我们来说就像自杀。

那时,我们的DevOps工程师带领团队更改了当前状态,但是更改并非一朝一夕就完成,这需要时间,并且需要每个人的帮助。


重组:

走向天堂的第一步是重组,从长远来看,这有助于稳定产品。 因此,我们从创建具有不同范围的团队开始,这一新的变化在团队成员(开发人员,技术负责人,产品经理)中建立了产品的主人翁感。 同时,我们创建了另一个团队,该团队由2个DevOps组成,其客户主要是开发人员,他们比以前拥有更快的交付速度,现在他们拥有特定的范围。 主要问题是随着时间的流逝,DevOps团队的技术负担开始增加,而我们的工作只是解决问题,处理性能而不改善任何事情。 ( 对于不认识的人来说,技术债务是指您在接受工作之前不对容量和需求进行任何分析时所获得的债务,这使您总是争执不休,不得不走捷径,这意味着应用程序更加脆弱在生产中,这意味着将来会有更多计划外的工作,并且像金融债务一样,利息成本会随着时间增长。)但是就像达尔文所说:

它不是生存最强的物种,也不是最聪明的物种,而是对变化最敏感的物种。


测量任何东西,测量所有东西:

组织变更后的第二步是对当前状态的评估,因此,我们建议我们需要开展对开发人员具有附加价值的项目,而不仅仅是处理支持,并且这需要所有团队的妥协。变得更加牵涉到所有问题的故障排除和解决,每当他们需要DevOps团队的请求时,教区主任就提出请求,并需要遵循具有合理SLA的预定义流程。

一旦DevOps团队有足够的时间,我们便开始真正的工作。 当然,我们想到的第一个项目是设置一个良好的监视工具,该工具需要用警报覆盖所有必要的指标。 当我们谈论指标时,我们需要区分三种指标:

指标类型

至于工具,我们选择了Datadog和Prometheus / Grafana,因为每种解决方案都有自己的用法。

Datadog仪表板
格拉法纳仪表板

无处不在的自动化

监控工作现在没有问题,想到的下一个项目是自动化部署,这可以视为CI的种子,因为我们可以拥有漂亮的仪表板,但是如果手动完成部署/回滚,每个人都会仍然不敢部署。

经过一番集思广益后,DevOps团队向开发人员介绍了开发流程,我们与他们讨论了一些重要点:

  • 构建期间口味之间的差异
  • 用于服务之间通信的端口
  • Https和SSL终止

要使部署自动化,需要存在一个质量保证和一个生产前环境,其本地配置与生产类似。 我们用于管道的工具是我们在自己的云中托管的Jenkins,我们将其置于源代码控制之下,以便跟踪管道中的更改,该过程分为7个阶段:

  • 准备:准备用于构建的环境
  • 签出:获取需要部署的特定分支
  • 编译:根据环境变量编译软件包
  • 发布:将工件发布到S3
  • 部署:将每个软件包安装在其特定的服务器中,然后重新启动服务
  • 清理:清理旧的已安装软件包
  • 通知:发送有关部署状态(成功或失败)的通知

但是,由于我们不打算处理许多部署,因此我们只需要一个主节点,而没有从节点。 为了启动管道,我们当然需要一些参数:

  • 环境(质量检查,预生产,生产)
  • 部署类型(平台,功能,修复)
  • 要部署的分支
  • 最后是国家/地区,因为我们正在为两个不同的国家/地区部署代码。
詹金斯部署管道
詹金斯管道参数

我们走在正确的轨道上吗?

现在,自动化项目已经完成,我们的KPI呈指数增长,并且与开发人员的反馈循环变得稳定:

  • 代码部署频率:从每月1次或2周增加到平均每天3次
  • 代码部署的前置时间:由于用户开始快速修复错误,并且新功能开始按时投放市场并产生重大影响,因此大大减少了代码部署的时间。
  • 变更失败率:由于我们在部署期间开始出现的故障越来越少,因此更改率也有所降低。
  • MTTR(平均修复时间):现在,开发人员可以快速部署,他们可以立即修复错误,而这不会减少MTTR。
  • MTTF(平均失败时间)和MTBF(两次失败之间的平均时间):我们开始部署失败的次数越来越少,这是由于QA环境接近Prod环境而造成的。

但是拥有自动部署并不是全部,我们需要通过集成更多的自动测试(单元测试,集成测试,回归测试,验收测试,性能测试)来达到持续集成的最后阶段,因为我们不希望开发人员开始出现IWOML综合症(可以在我的笔记本电脑上使用),即使仅在QA环境中也是如此。


整体与微服务,我们回到地狱了吗?

由于我们的平台是整体的,因此开发人员很难添加新功能,因此他们开始为所有内容添加微服务。 对于处理大量微服务的DevOps,这会让我们回到过去的噩梦。 因此,我们发现我们需要研究一种允许我们进行以下操作的解决方案:

  • 具有微服务的开发/质量保证/产品环境
  • 允许发现微服务并将其添加到CI服务器
  • 允许开发人员按照命名约定将容器中的微服务发送到私有注册表
  • 通过VPN限制对经过身份验证的用户的访问
  • 平台的配置需要自动进行
  • 该平台需要扩展和扩展
  • 我们需要监视平台:运行状况,指标,日志
  • 保护所有服务之间的通信
  • 确保服务的高可用性。

经过一些基准测试,我们得出了将KubernetesDocker结合使用的结论:

该实现应允许我们自动创建,更新和管理K8s集群基础架构的多个环境,并且我们决定使用Terraform作为基础架构即代码工具,etcd用于服务发现以及法兰绒来管理网络。 在另一篇文章中,我将详细介绍此设置。


DevOps团队中的我们没有应开发项目的指南,我们从已有的项目开始,然后遵循我们的需求,或更像是开发人员的需求。 我们仍然有很多地方需要改进,但是只要DevOps思维定势扎根于每个开发人员的心中,我们就不会有任何问题。 就像DevOps的教父所说:

“ DevOps不是目标,而是不断改进的永无止境的过程。” Jez Humble说道。