菠菜网站搭建怎么做,简洁的网站建设合同,wordpress 做博客,网络营销主要是学什么的一个成功的SRE团队可以为组织带来巨大价值#xff0c;帮助组织高效完成价值交付。本文介绍了Mission Lane公司打造SRE团队的经验和实践。原文: Building a Successful SRE Team 简介 当我加入Mission Lane时#xff0c;是公司仅有的两名站点可靠性工程师(SRE)之一#xff0c… 一个成功的SRE团队可以为组织带来巨大价值帮助组织高效完成价值交付。本文介绍了Mission Lane公司打造SRE团队的经验和实践。原文: Building a Successful SRE Team 简介 当我加入Mission Lane时是公司仅有的两名站点可靠性工程师(SRE)之一而另一位就是我的老板SRE团队的经理后来成为了平台组织的主管。我们被要求组建一支拥有可观察性和开发者经验的SRE团队从而开始了这一为期三年的旅程建立了一个成功的SRE组织并为Mission Lane带来巨大价值。如今SRE团队由四个人组成支持250个微服务和130名开发人员每天向各种环境发布数百个版本每天产生近10亿次日志和跟踪。 SRE团队专注于以下事项: 为Mission Lane开发者创建标准化helm chart 管理自动分布式跟踪 创建可观察性技术栈每秒处理50万条日志和跟踪 为应用自动化处理金丝雀发布希望显著降低使用门槛 托管依赖自动更新 建立有用的服务目录 SRE团队还和姐妹团队(云平台工程(CPE)和DevSecOps(DSO))一起建立了几乎完全自助服务的开发平台开发人员只需要提交三个PR(以及一些关于命名的讨论)就可以完成从想法到生产的流程。 这也是我第二次参与建立成功的SRE团队(第一次是在Capital One)以下是我学到的四条经验教训可以帮助我们建立成功的SRE组织。 专注于开发人员培训 专注于正确的抽象 专注于自助服务 用自动化取代工作 专注于开发人员培训 当我们花一整天时间研究某项技术或平台时就能成为这方面的专家。而当我们成为某一技术领域的专家时就会习惯平台的怪癖、问题和边缘情况。此外我们很快就会遇到高级用户问题[1]并且希望尽可能多进行自定义。我们确切知道什么可用系统如何工作/如何连接并且对事物如何工作有很好的心理模型。 但SRE的客户是开发人员他们专注于通过开发服务交付业务价值。开发团队有不同层次的工程成熟度使得他们有能力关注可靠性、工具等而非只是直接的业务需求。他们需要能够尽可能快速、轻松的交付价值同时不损害安全性、可靠性或可伸缩性。因此开发人员培训至关重要。 在Mission Lane有中心化SRE团队支持大约20个产品团队拥有大约250个微服务。我们每个季度都会选择两到四个产品团队将SRE嵌入团队一个月。在这个月里SRE需要关注项目健康状况检查清单以保持目标专注但主要目标是培训开发人员了解开发人员如何与平台互动了解开发人员遇到的所有小问题并通过授之以渔来帮助他们更轻松的工作。以下是一些SRE可以帮助解决的问题: 修复对某些特定非关键(但非常恼人的)端点不起作用的跟踪 帮助开发人员了解使用 Flagger [2]和Istio的金丝雀版本如何工作 帮助开发人员添加仪表板创建警报调整或抑制乱七八糟的告警 帮助开发人员能够从本地部署到开发集群 这是我们成立SRE团队一年后开始的项目非常成功。开发人员喜欢与SRE进行简短、集中的交互。SRE与产品团队建立了联系向我们展示了开发人员遇到的各种问题或关注点并且帮助我们构建工程组织的一般知识。 专注于正确的抽象 DevOps文化转型主要集中在左移。随着组织成熟我们意识到也需要下移[3]。我们需要编写正确的抽象帮助团队用更少的资源做更多的事情。 在Mission Lane的早期我们的Kubernetes集群上没有抽象。当时我们有一个非常强大的基于ArgoCD、GKE和CNRM的GitOps流水线。但开发人员需要手工编写k8s清单然后通过ArgoCD将其应用到k8s集群中。虽然这会导致大量重复的YAML但真正的问题是当我们需要应用大规模更新时。需要为所有部署设置安全上下文吗需要换一个新的Ingress吗想要应用环境变量或注释吗我们不得不编辑数百个yaml文件。虽然其中一些可以通过编程语言自动化但社区已经解决了这个问题。 大约在SRE团队成立9个月后我们发布了ML Service Helm Chart的1.0.0版本。这个chart最终被Mission Lane 95%的服务所使用并且出现了数百个版本。它允许团队在我们的集群中可靠、安全的启动和运行允许极端定制在大多数情况下遵循k8s API规范完全允许重写所有设置同时提供相同的默认值以促进良好的应用健康状况和实践。 这个helm chart使我们能够为整个组织解决问题。当我们发现需要添加设置时可以为整个组织发布带有更新配置的新版本helm chart。新版本严格遵循Dont Break User Space原则带有大量测试并自动管理非兼容API的更改。 这种下移而不是左移的范式出现在工具、我们编写的抽象以及我们谈论开发人员的方式中。把他们当作自己领域的专家认识到他们可能不是你领域的专家看看你能怎么帮助他们以自助的方式获得成功。 专注于自助服务 SRE团队应该能够成为工程组织的力量倍增器。如果必须为每个产品团队雇佣一个SRE就意味着失败。专注于允许开发人员做出自助决策并且只在出现问题时才来寻求帮助这可以使力量倍增。亚马逊和谷歌不会强迫我们每次想要开启一项服务时都与技术支持沟通也不会强迫我们在发布新产品时都与工程师沟通。相反他们通过API和UI使我们能够自助服务只有在无法解决问题时才会与他们交谈。如果我们编写了良好的文档并拥有直观的流程/API那就可以帮助无数开发人员而不用不得不与每个开发人员进行沟通。 这种理念在SRE团队成立之前就存在于Mission Lane。在创建SRE时底层GKE集群和自动化工具非常好这是CPE团队的功劳。但是专注于自助服务让我们能够执行办公时间模式(office hours model)即开发者可以每周来一次并提出问题其他情况我们可以通过slack支持频道让开发者能够提出问题并获得答案。 使用允许开发人员与集群和服务进行安全交互的工具可以确保流程在不限制选择的情况下不会出现错误配置。当问题出现时请确保评估流程或工具看看哪里可以做得更好。信任你的开发者开发者就像用户一样他们很少故意做错事出问题时可能只是有一个xy状况[4]。 使用能够在相同位置快速给出反馈的工具。在早期CPE决定将PR作为所有反馈的中心。使用主线开发模式[5]并让所有工具与PR交互意味着有一个一致的心智模型团队可以只通过代码所有者和评审进行自助服务。几乎平台团队引入的每个工具都使用PR作为界面机制极大提高了开发人员的速度和反馈。 用自动化取代工作 消除重复劳动[6]是SRE的关键要素是这份工作的基础也是支撑这份工作的哲学。如果一遍又一遍重复做同样的任务每次纠正同样的问题或者甚至编写非常好的运行手册[7]都表明你没有消除足够的重复劳动。虽然机器不应该提供审批但几乎所有其他工作都可以自动化。打开某些PR模板化repo和文件甚至响应某些错误都可以自动化。 这是SRE在Mission Lane的核心原则努力使自己尽可能自动化。这意味着使用Cortex.io这样的工具来构建模板和记分卡编写自己的数据库分析器来帮助团队调整连接设置和数据库大小编写自动修复Elasticsearch问题的工具或者在PR中用现成的分析器来帮助捕获常见问题我们努力消除做特定任务的需要从而使我们能够专注于更高层次和更大组织范围的问题同时还让我们可以基于有限数量的SRE来扩展和支持快速变化的开发组织。 结论 建立成功的SRE团队是困难的。需要非常优秀的工程师他们知道如何专注于正确的问题并且是优秀的沟通者。但这一切最终都是值得的SRE团队将成为整个组织的力量倍增器帮助团队减少意外事件、改善开发人员体验、提高代码质量。只需记住: 关注于开发人员培训。提高开发人员的知识和期望会带来巨大好处。 专注于正确的抽象。下移而非左移。抽象掉那些对客户不重要的东西。 专注于自助服务。开发人员应该能够完全自主的与平台进行交互任何标准操作都不需要和SRE交谈。 让自动化帮助我们摆脱工作。继续努力不要自满。推动不断改进自动化这样就可以做新的和有趣的事情 你好我是俞凡在Motorola做过研发现在在Mavenir做技术工作对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣平时喜欢阅读、思考相信持续学习、终身成长欢迎一起交流学习。为了方便大家以后能第一时间看到文章请朋友们关注公众号DeepNoMind并设个星标吧如果能一键三连(转发、点赞、在看)则能给我带来更多的支持和动力激励我持续写下去和大家共同成长进步 参考资料 [1] The power user problem: https://thesocietypages.org/cyborgology/2015/09/07/the-power-user-problem [2] Istio progressive delivery: https://docs.flagger.app/tutorials/istio-progressive-delivery [3] Richard Seroter on shifting down vs shifting left: https://cloud.google.com/blog/products/application-development/richard-seroter-on-shifting-down-vs-shifting-left [4] The XY Problemm: https://xyproblem.info [5] Trunk Based Development: https://trunkbaseddevelopment.com [6] Eliminating toil: https://sre.google/sre-book/eliminating-toil [7] Stop Writing Great Runbooks: https://staysaasy.com/software/2022/02/12/runbooks.html - END - 本文由 mdnice 多平台发布
