Amir Kirsh
一年一度，Yalla DevOps 已成为了解 DevOps 世界的最佳窗口。Yalla DevOps是由 JFrog 组织的开发者社区论坛，今年于7月8日（星期四）在美丽的特拉维夫大学校园举行。通过下面的这段简短视频，大家可以感受到现场的气氛：
本文将主要总结论坛中的干货和亮点。这些内容当然也掺杂了我的主观判断，因为挑选的内容也都是我觉得重要的部分。如果我错过了任何重要的内容，或对论坛上的信息有任何误解，我提前道歉。也欢迎大家通过www.incredibuild.com给我发邮件（我的邮箱：amir.kirsh）指正，尽量不要直接发送信息。我会认真核查，如出现错误一定及时更正。
除了文中总结的一些精彩演讲之外，本次论坛还设置了一些大型公司展示区，其中推荐了 DevOps 领域优秀的产品和解决方案，如 Granulate、env0、 Replicated、DoubleVerify、 Spectral、 Coralogix、Simloud，和 minute media。完整列表，请点击链接查看。
图片来源：Yalla DevOps – env0’s swag – summer treats
未来发展趋势
JFrog 首席执行官 Shlomi Ben Haim 首先通过分析未来趋势开启了论坛，他主要从 DevOps 的人才及其专业领域展开。如今，行业对 DevOps 工程师的期望似乎更高了，企业都在寻找具备各项能力的 DevOps 全才，而不是“Kubernetes 专家”或“Jenkins 专家”。因为这些全才能够监督整个生态系统，同时还能看到运营和维护（Ops）上的不足。
意料之内，另一个讨论的趋势是云计算。Shlomi 展示了一份 JFrog 调查报告，报告显示世界正迅速向云前进。如果两年前，在生产中以某种方式使用云计算技术的公司数量为 30%，现在这个数字已经翻了一番。到 2021 年，数据已飞升至 60%。
但是，开发生态系统者的部分产品却开始走下坡路。例如，Jenkins 的市场份额下降了 14%，目前是 62%（仍然很高），因为市场的主流已偏向 DevOps 端到端方案，而不太选择仅限于 CI 或 CD 的解决方案。
至于趋势或热词 DevSecOps，Shlomi 觉得这个术语的概念依然很模糊。因为目前还没出现开发和安全都可靠的自动工具，可以填补手动操作的空缺。所以整个方向依旧不太明朗，但肯定会有新的工具和产品出现。
Shlomi邀请 Elastic 联合创始人兼首席执行官 Shay Banon 参加讲座，讨论开源和 DevOps。Shay 是一个很优秀的领导者。早在2004年，Shay 对商业产品就开始感到失望，于是从起步阶段开始设计并见证了顶级开源产品的诞生。其中 Elastic 的第一行代码是就是由 Shay 本人编写。因此，对于开源的话题，Shay 显然非常有话语权。
Shay 首先分享了他对开源世界的热情：这个世界中，如果你出现问题，在Bugzilla 中打开了一个缺陷报告，或者如果你在用户组中提出了问题，那些代码库贡献者通常会在几个小时内给出有效的解决方案。这比求教那些对代码并不感兴趣的技术支持人员有效多了。
Shlomi 接着提问 Shay，谁更适合管理软件公司，技术人员（比如 Shay）还是有商业背景的人（比如 Shlomi）？当然，在这次讨论中，他们也很自然地提到了两个公司市场份额差异（Elastic 为135亿美元，而 JVROG“仅”为 43.3 亿美元）。至于这个问题的答案，大家最后也没有定论。
如何快速实现质量和速度的提升？
这次演讲由 Vonage 的 Avital Tzubeli 主持。
Avital 分享了 Vonage的经验，从一年发布 3 到 4 次，到每天发布，这个进步并不容易。就像烹饪一样，菜谱可能看起来很简单，但一不小心，不仅会把厨房弄得一团乱，也会得到一些奇怪的“黑暗料理”。因此，发布加速需要在测试方面做大量工作，从功能测试到负载测试、压力测试等，还需要关注新的流程以及细节，不能只是简单意义上的加快速度。
微服务“简单”，依赖关系复杂：构建云原生 CI/CD 的正确方法
Komodor 的首席技术官和联合创始人 Itiel Shwartz 解答了如何打破整体的问题，这不仅需要考虑编码（我们知道如何做微服务），更是落实到 CI/CD 依赖性、构建、测试和部署环节上。
快速发射还是卫星事故？
图片来源：Yalla DevOps 论坛成员
参与下面的讨论的成员有：SpaceIL 的联合创始人和领导者Kfir Damari，Grove Ventures 的 Omri Green，JFrog 的联合创始人和首席数据科学家 Fred Simon，空间行业高级顾问和专家 Adi Ninio Greenberg 博士，担任主持人的是来自 TLV Partners 的 Eliran Rubin。
尽管与 DevOps 世界没有直接联系，但围绕空间行业新市场和发展的相关讨论很有启发意义。为什么？航天工业面临的困难和解决方案陆续影响到了其他行业，其中涉及农业、材料工程、3D打印、电池、食品技术、硬件、软件等等。
风险投资公司如何在航天产业实现商业模式，在得到回报之前，任何项目都是以高投资开始的？这一切与 DevOps 有什么关系？
当你的投资数额高达数百万美元时，你肯定想要尝试最前沿的创新操作方式，也需要一个好的软件流程。尽管许多太空项目最初是从国防工业开始的，这是一个相对老派的行业，但现在新项目使用的是真正的尖端工艺和技术。在太空行业，软件更新是常态，在执行任务期间或在生产过程中都会出现。因为这些软件必须运行，不能出现任何失误。
Adi 还提到，十年内约有四万颗卫星上太空，围绕全球运行，这个挑战不小。这些卫星归公司和政府所有，需要有效规划导航及航线规则，以避免碰撞出现。
Kfir 总结道，年轻一代的技术灵感和教育应该成为 SpaceIL 未来规划和行动的关键。
深入研究开放政策代理（OPA）+ Conftest + GateKeeper：Kubernetes 正在实施的政策
datree.io 的 Shimon Tolts和Noaa Barki 带我们了解了 Kubernetes 管理策略中的挑战和解决方案，包括如何在 Datree 实施策略，防止错误或劣质的配置进入生产环节。我们越来越依赖自动化的 DevOps 进程，出错率也将降低，但是我们还是需要严格地监督和控制。
成为好邻居——在无服务器世界中限制费用
AWS 的 Boaz Ziniman 更侧重于 AWS 体系结构，这与所有分布式体系结构相关。
“成为好邻居”，意味着有效利用资源。即使只需执行一个进程，你也必须了解他人的需求——做一个“君子”，不要过度利用，学会为他人留余地。
Boaz 则从 Nielsen 的案例研究说起，每天处理55T数据（ great AWS 系列“我的架构”中的一部分）。
关注无服务器和自动扩展，你必须正确处理以下环节：保留并发、节流、异步流和“扇出”。等待另一个服务回应，耗费的是云资源费用和等待时间。因此，建议使用队列功能（如Amazon sqs）， pub/sub（如Amazon sns），或具有适当节流配置的 EventBridge 功能。
Boaz 讨论了 RDBMS 连接的问题，主要因为 lambda 不能连接到池。他列举了一些解决方案：如可以在 lambda 和 DB 之间使用队列，并将数据从队列持久化到 DB。或者也可以使用 AWS 提供的新功能 RDS Proxy。你还可以使用缓存解决方案，如 Amazon ElastiCache。此外，值得注意的是，lambda 热启动可能在 local /tmp 目录下使用高达 500MB 的持久化存储，这些存储也可用于缓存。
下一个重要建议，是始终使用超时设定和退出重试！
超时设定对于避免长时间等待和关闭不相关进程非常重要。
默认超时设定（连接，db）通常不好：要么太长，要么无限长。退出重试意味着在重试之间增加一些时间，建议在重试周期的间隔中添加一些随机性，以避免触发意外的相关重试周期，这往往会导致循环失败。请记住，配置超时是相互关联的操作。
“僵尸”机器！
Shir Chaimi 主要讲解了如何通过自己的解决方案处理实际问题（是的，DevOps 可以实现代码了！）。她谈到了如何通过分析 IPMI（IPMI 截图）在私有云环境中自动恢复“僵尸”机器。该解决方案可在 outbrain 使用，目前可处理 36 种不同的问题。缓解选项包括：发送创建键盘输入信号，让机器不再等待特定用户输入，运行 CLI，以及自动打开硬件故障（如内存故障或磁盘故障）的票据。
Knative–部署和管理基于容器的无服务器工作负载
从僵尸机器中恢复过来，Agmatix 的首席技术官 Elad Hirsch 讲解了如何使用K8S 对 Knative 项目进行无服务器（其实应该是隐藏服务器）管理和部署。
当 Prometheus 也无法承受重担时
随后，Riskified 的 Liron Cohen 介绍了一种很好的选择工具的方法，扩展 Prometheus 的使用。他先后推荐了三种工具：M3、Cortex 和 Thanos.
Risky 最终选择了 Thanos，其优点是：简单，文档记录详细，支持推拉模式。
当然，正如演讲者所说，这种选择与其工作环境的需要有关。另外，他还指出了每种工具的利弊。
重新思考现成工具的可观测性
接下来是 Replicated 的客户工程副总裁 Dexter Horthy，他谈到了将一些云环境中的“现成软件”引入本地或私有云环境的挑战。在这种环境中，许多决策都无能为力。
作为软件供应商，我应该如何为客户环境（本地、私有云等）安装所需软件？我需要为我的产品提供一系列 bash 脚本吗？我应该用各种部署组合来证明吗？Dexter 做了计算——目前大约有1.2 万种可能的组合（平台、日志、监控等），并且数据还在不断增长…
他建议的方法是使用 K8S，让设置简化，这听起来并没什么新意，但要使用正确，也是一个不小的挑战。
干货满满的小型讨论
这次活动有八次干货满满的小型讨论。你可以在论坛议程上看到摘要内容。
下面是小型讨论中的一些要点（选自八个小型讨论，但由于讨论时间太短，难以追踪到观点的具体作者。不过内容总是比来源重要）：
- 服务和代码可能遭到黑客攻击。Codecov 曾遭到黑客攻击，或者更具体地说，其云存储遭到黑客攻击，而且目前仍有一些项目使用被黑客攻击了的版本。管道是代码的一部分，因此必须进行保护，且严格遵循安全警报和更新建议。
- AWS 讨论了各种使用场景。多帐户：使用不同的云帐户，管理不同的环境或用户，然后使用相同的管道部署到不同的帐户。y.
- 作为 DevOps 经理加入一家新公司：首先应该做什么？问问自己：我的开发/运营人员最害怕的是什么？问题的答案就是你的工作重点。手动完成的事情经常会中断，但要分析原因。
- 我们在 DevOps 中讨论事件和指标，但我们没有充分或正确地使用。DevOps 代码可以通过多种方式完成，不同的方法会对管道的维护产生巨大影响。
最后——我们都是 SRE 冠军！
Ant（on）Weiss，SRE（Site Reliability Engineer ，网站可靠性工程师）顾问和导师，谈到了指导 SRE 冠军的过程。他还指出了 DevOps 和 SRE 之间细微差别（主要是薪资提升 15%），以及为什么即使工资不变，男性工程师比女性工程师（没有性别歧视）更追崇额外的工作“头衔”或荣誉。
另外，他还提到了 SRE 瓶颈。解决这个瓶颈，需要平均分配运维（Ops）和工程任务。为了实现这一目标，团队中既需要有 SRE 冠军，而且这个冠军最好是由内部 DevOps 工程师指导。
你应该准备一次“TRIP”：包括Training（培训）, Responsibility（责任）, Involvement（参与）和 Preparation（准备）。
如果Trip （旅行）愉快，你的团队也自然会诞生 SRE 冠军！
最后，我们唱着皇后乐队的《We’re the Champions》结束了论坛。
Anton 准备了 YouTube 的视频音乐作为结尾，但最终效果一般，所以我们都旁若无人地乱唱一通。不过这个氛围很适合结束论坛。当然，也适合作为本篇博客的结尾。
