DevOps适用于小团队吗?
Posted 分布式实验室
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了DevOps适用于小团队吗?相关的知识,希望对你有一定的参考价值。
在第一阶段,互联网应用程序的构建和部署与“伸缩包装”软件的运输方式类似。三个不同的工作角色(开发,QA和运营)相互协作,经过很长的工程周期将应用程序从开发转移到生产。在此阶段,每个应用程序都部署在专用数据中心或托管设施中,这进一步需要熟悉特定站点网络,硬件和系统管理的操作人员。
在第二阶段,主要由亚马逊和谷歌在90年代末和00年代初带头,互联网应用程序在超高速发展的公司中开始采用类似于现代DevOps运动的做法(松散耦合的服务,敏捷开发和部署,自动化等等)。这些公司仍然运行私有的(大型)数据中心,但由于涉及的规模,他们开始开发集中式基础架构团队去解决所有服务所需的常见问题(网络,监控,部署,配置,数据存储,缓存,物理基础设施等)。然而亚马逊和谷歌从未完全统一开发工作角色(亚马逊称之系统工程师,谷歌称之网站可靠性工程师)以及认识到每个人所涉及的不同技能和兴趣。
在第三阶段或云原生阶段,互联网应用程序现在依赖托管弹性架构以从头开始构建,通常这由“三大”公有云服务商之一提供。尽可能快地将产品推向市场的主要原因一直是因为产品失败的可能性高,但是在云原生时代,“开箱即用”的基础技术允许一种比以前更加笨重的迭代速度。在这个时代开始的公司的另一个定义特征是避免聘用非软件工程师角色。可用的基础设施基础是如此相当强大,他们认为创业资金应更好地花在可以同时进行工程和运营(DevOps)的软件开发人员身上。
根据我的经验,成功的早期创业公司工程师是一个特殊的工程师。他们具有风险承受能力,学习速度极快,无论发生何种技术债务都能尽快完成工作,通常可以在多种系统和语言中工作,并且通常具有操作和系统管理的先前经验,或者愿意学习所需知识。简而言之,典型的创业工程师非常适合成为DevOps工程师,无论他们是否想这样子称呼自己。
如上所述,现代公有云为构建提供了令人难以置信的基础架构。过去的大多数基本操作任务都已自动化,剩余的底层足以发行最小的可行产品去验证是否有适合的产品市场。
我坚信,当开发人员被迫on-call并对他们编写的代码负责时,系统的质量将会提高。没有人喜欢经常被寻呼。这个反馈循环构建了一个更好的产品,正如我在(1)中所描述的那样,吸引到早期初创产品工作的工程师非常愿意学习和完成操作工作。鉴于对可靠性差的初创产品通常几乎没有反响,这一点尤为如此。可靠性需要足够好以使产品找到适合市场并进入超高速发展阶段。
人员增长率迅速增加,对通信和工程效率造成严重压力。我强烈推荐阅读The Mythical Man-Month[2](在最初出版近50年后仍然具有相关性),以获取有关此主题的更多信息。
上述几乎总是导致从单体架构向微服务架构转变,这是一种解耦开发团队并提高通信和工程效率的方法。
从单体到微服务架构的转变将系统基础架构的复杂性提高了几个数量级。网络,可观察性,部署,库管理,安全性以及以前不难解决的数百个其他问题,这些现在都是急需解决的主要问题。
与此同时,超高速发展意味着流量增长和由此产生的技术扩展问题,以及对完全失败和次要用户体验问题的更大影响。
正如我以上描述,现代云原生技术和大量抽象允许使用越来越复杂的基础设施来构建功能非常丰富的应用程序。自然而然,大多数公司将不再需要一些专业技能,如数据中心设计和运营。
在过去的15年中,业界一直专注于软件工程是所有学科的根本。例如,微软淘汰了传统的QA工程师,并将其替换为软件测试工程师,其理念是手动QA效率不高,所有测试都应该自动化。同样,传统的运营角色已经被站点可靠性工程师或类似的所取代,其理念是手动操作效率不高,并且扩展的唯一方法是通过软件自动化。首先声明我是同意这些趋势的,自动化是一种更有效的扩展方式。
通用型与专家。更复杂的应用程序和体系结构需要更多的专业技能才能成功,无论是前端,基础架构,客户端,操作,测试,数据科学等。这并不意味着全能型不再有用,或者全能型不能学会并成为专家,它只是意味着更大的工程组织需要不同类型的工程师才能取得成功。
所有工程师都不喜欢去做所有的事情。有些工程师喜欢做全栈。有些人喜欢专业化。有些人喜欢编写代码。有些人喜欢调试。有些喜欢UI。有些喜欢系统。一个支持各类型专家不断发展的工程组织必须解决这样一个事实,即员工的幸福感有时涉及某些具体类型的问题,而非其他。
所有工程师也不都擅长做所有事情。在我的整个职业生涯中,我遇到了很多很棒的人。某些人可以从IDE中的空文件开始,从头开始创建一个令人难以置信的系统。与此同时,这些人对如何运行可靠系统,如何调试它们,如何监控它们等等几乎没有直觉经验。相反,我一直在进行许多令人激动的访谈循环,其中一个真正令人难以置信的是运营工程师可以纯粹通过调试方面的专业知识和如何运行可靠系统的天生直觉,对整个组织产生巨大好处,但他们被拒绝仅是因为没有展示“足够的编码技能”。
迁移到微服务。当一个工程组织达到约75人时,几乎可以肯定有一个核心基础设施团队开始开发构建产品团队构建微服务所需的基础通用功能。
纯粹的DevOps。与此同时,产品团队被告知要做DevOps。
可靠性顾问。在这种组织规模上,那些倾向于从事基础设施工作的工程师很可能是那些在该领域具有先前运营经验或良好直觉的工程师。这些工程师不可避免地成为事实上的SRE/生产工程师,并作为顾问来帮助组织内的其他成员,同时继续开发业务运行所需的基础架构。
缺乏教导。作为一个行业,我们现在希望雇用可以介入开发和运营互联网服务的人。然而,我们普遍在新员工以及执行这项任务所需的继续教育方面做得很糟糕。当我们从不教授技能时,我们怎能指望工程师具备操作直觉?
支持失败。随着工程组织招聘率的不断提高,核心基础架构团队不再能够在继续构建和运营对业务成功至关重要的基础架构的同时还要保持支持帮助产品团队完成运营任务。基础设施工程师在其现有工作量的基础上,作为组织范围的SRE顾问,承担双重责任。每个人都明白培训和文档是至关重要的,但是很少有人优先安排去完成这两件事的时间。
职业倦怠。更糟糕的是之前描述的情况造成了人员流失并降低了整个组织的士气。产品工程师觉得他们被要求做他们不想做或者没有被教过的事情。基础设施工程师在提供支持的重压下开始倦怠,虽然知道培训和文档迫切需要但却无法优先处理它,当同时在保持整个公司的现有系统以高可靠性运行。
仅是SRE需时刻待命还是软件工程师也分担待命职责?
SRE是否实施实际工程以及自动化,还是他们仅需要执行手动和重复性任务,例如部署,重复页面解析等?
SRE是属于核心咨询机构还是嵌入到产品团队?
认识到运营和可靠性工程是一个独立且极具价值的技能组合。我们急于实现一切自动化以及软件工程师可互换的想法,使得与软件工程师同等价值的工程人员的一部分边缘化。运营工程师和软件工程师是合作伙伴,而不是可互换的齿轮。
SRE不是随叫随到的,监控仪表面板或是只会部署的猴子。他们是专注于可靠性任务而非产品任务的软件工程师。理想的结构要求所有工程师会执行基本的运营任务,包括待命on-call,部署和监控等。我认为这非常重要,因为它有助于避免可靠性和软件工程师之间的类/工作分层,并使软件工程师更直接地对产品质量。
SRE应该嵌入到产品团队中,而不是向产品团队工程经理报告。这允许SRE与他们的团队融合,获得相互信任,并且仍然具有适当的核查与平衡,以便在尝试权衡可靠性与功能时可以进行真正的对话。
嵌入式SRE的目标是通过实施面向可靠性的功能和自动化,指导和教育团队其他人员的运营最佳实践来提高产品的可靠性,并充当产品团队和基础架构团队之间的联络人(文档反馈,痛点,所需功能等)。
任何希望参与竞争的新技术公司都需要DevOps风格的敏捷开发和自动化。
公有云原生基元以及一个小型的核心基础架构团队可以允许工程组织在由于缺乏教导和角色特性而开始出现运营损失之前扩展到数百名工程师。
想要在可掌控的人员扩展问题上获得成功,需要对新员工和继续教育,文档以及嵌入式SRE团队的开发进行真正的投资,这些团队可以在产品团队和基础架构团队之间架起桥梁。
https://twitter.com/mattklein123/status/1001979384968957952
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
以上是关于DevOps适用于小团队吗?的主要内容,如果未能解决你的问题,请参考以下文章