Master

技术

采纳?

  • API扩张-收缩模式,有时也被称为并行修改,很多人对这个模式都很熟悉,尤其是在与数据库或代码一起使用的时候,而在API方面我们只看到较低的采用率。它具体指的是,人们通常会采用复杂的版本控制和破坏性的修改来实现API升级,而其实简单的扩张再收缩就可以满足需求。例如,在想要弃用API中的某个元素时,先添加一个不包含这个元素的API,然后在消费者都切换到新的API之后,再删除该元素以及包含该元素的旧API。这种方式确实需要API消费者的一些协调和可见性,可能需要通过消费者驱动的契约测试之类的技术来实现。

    历史信息
  • 我们将机器学习的持续交付(CD4ML)作为所有部署在生产环境中的机器学习解决方案的默认起点。许多组织越来越依赖于机器学习解决方案来提供客户产品和内部运营,因此将持续交付(CD)所获得的经验教训和良好实践应用于机器学习解决方案具有良好的商业意义。

    历史信息
  • 随着应用程序开发变得越来越动态和复杂,以一致的风格交付可访问且可用的产品变成了一个挑战。在拥有多个团队从事不同产品开发的大型组织中,尤为如此。 设计体系 定义了一组设计模式,组件库,以及良好的设计和工程实践,以确保数字产品的一致性。在过去的公司风格指南基础上,设计体系提供了易于查找和使用的共享库和文档。通常指南是以代码的形式编写,并且受版本控制管理,所以相比简单的文档,它更明确且易于维护。设计体系已经成为跨团队和学科产品研发时的标准方法,因为它可以使团队更加专注于解决围绕产品本身的战略挑战,而无需在每次需要新的视觉组件时都重复造轮子。

    历史信息
  • 正如本期雷达主题之一所指出的那样,业界在创建和支持内部平台的“平台工程产品团队”中积累了越来越多的经验。组织中的团队使用这些平台,可以加速应用程序开发,降低运营复杂性并缩短产品上市时间。随着采用率的提高,我们对于这种方法的好和坏的模式也越来越清楚。创建平台时,至关重要的是要明确定义可以从中受益的客户和产品,而不是凭空建立。我们不仅要谨防分层平台团队,它保留了现有技术孤岛,只是贴上了“平台团队”的标签而已,还要小心工单驱动的平台运营模型。当考虑如何最好地组织平台团队时,我们仍然是团队拓扑概念的忠实拥护者。我们认为平台工程产品团队是一种标准方法,并且是高性能IT的重要推动者。

    历史信息
  • 我们强烈建议组织在确实需要使用云服务帐户的时侯确保这些云服务帐户的凭证能得到轮换。轮换是安全性的三个R之一。除非发生安全事件,否则组织很容易忘记这些帐户。这会导致拥有不必要的广泛权限的账户长期处于使用状态,并且缺少如何替换或轮换它们的计划。定期应用云 “服务帐户轮换方法” 还提供了运用最小权限原则的机会。

    历史信息

试验?

  • 由于云服务变得越来越常见,并且创建 云沙箱 变得更加容易且可大规模应用,我们的团队因此更倾向于使用完全基于云(相对本地而言)的开发环境,并以此来减少维护复杂度。我们发现用于本地模拟云原生服务的工具限制了开发者对构建和测试周期的信心,所以我们将重点放在标准化云沙箱上,而不是在开发机器上运行云原生组件。这样的方式可以使基础设施即代码实践得到更好的强制应用,并为开发人员提供沙箱环境良好的适应过程。当然这种转变也存在风险,因为它假定开发人员将完全依赖于云环境的可用性,并且可能会减慢开发者获得反馈的速度。我们强烈建议您采用一些精益治理的实践来管理这些沙箱环境的标准化,尤其是在安全、访问控制和区域部署方面。

    历史信息
  • Contextual bandits 是一类非常适用于解决探索/利用权衡问题的强化学习算法。该算法以赌场中的“老虎机”命名,通过探索不同的选择,学习有关预期结果的更多信息,并通过利用表现良好的选项来平衡该结果。我们已经在一些场景中成功地使用了该技术,在这些场景中只使用了少量的数据来训练和部署一些机器学习模型。事实上,我们可以在此探索/利用的权衡过程中添加上下文,使它适合于各种用例,包括 A/B 测试、推荐和布局优化。

    历史信息
  • 在为应用构建 Docker 镜像时,我们常常会考虑两件事:镜像的安全性和大小。通常情况下我们会使用容器安全扫描工具来检测和修复常见的漏洞和风险,并使用 Alpine Linux 之类的小型发行版来解决镜像过大和分发性能的问题。然而随着安全威胁的增长,消除所有潜在的攻击面变得空前重要,这就是 distroless Docker images 正成为部署容器默认选项的原因。Distroless Docker images 通过放弃完整的操作系统发行版来减少内存占用和依赖关系,它还可以减少安全扫描噪声和应用程序攻击面。此外,这一技术还意味着需要修补的漏洞更少了,镜像更小性能也更好了。Google 针对不同的语言发布了一套 distroless container images ,你可以使用 Google 构建工具 Bazel 或者简单地使用多阶段 Dockerfiles 创建 distroless 的应用程序镜像。请注意,默认情况下,distroless 容器没有用于调试的 shell,不过,你可以在网上轻松地找到包含 BusyBox shell的 distroless 容器调试版。Distroless Docker image 是 Google 开创的技术,根据我们的经验,这种技术的应用仍然主要局限于 Google 生成的镜像,如果有更多的供应商可供选择,我们会更放心。另外,在使用 Trivy 或类似的漏洞扫描器时要小心,因为只有较新版本才支持 distroless 容器。

    历史信息
  • Ethical OS背后的组织——Omidyar网络,是eBay创始人Pierre Omidyar发起的一个自述为致力于社会变革的冒险。Omidyar网络最近新发布了一个名为Ethical Explorer的版本。新的Ethical Explorer在Ethical OS实践得来的经验教训的基础上,增加了更深入的问题供产品团队考虑。Ethical Explorer可以在这里免费下载,并可折叠为卡片来引发讨论,这些卡片上有针对技术上的若干种“危险区”的一些开放性问题,包括监视(使用我们产品或服务的人是否可能追踪或识别其他用户信息?)、虚假信息、排异排外、算法歧视、沉迷上瘾、数据控制、安全攻击以及权限过大。其中的实战指南包括一些工作坊、开启对话的思路和获得组织支持的技巧。为了让我们的行业更好地发挥数字社会当中的伦理外部性(ethical externalities)作用,我们仍然有很多工作要做,但我们已经使用Ethical Explorer开展了一些卓有成效的产品讨论,并且对产品决策在解决社会问题中的重要性的认识不断扩大也同样鼓舞了我们。

    历史信息
  • 我们经常被要求更新、升级或者修正那些原本不是由我们构建的遗留系统。有时,我们需要注意一些技术问题,比如提升性能和可靠性。解决这些问题的常用方法是使用与用户故事卡相同的格式创建“技术故事卡”,但以技术成果而非业务成果作为目标。但是这些技术任务通常很难估计需要的时间,花费的时间比预期的要长,最终也时常会得不到预想的成果。另一种更成功的方法是应用 假设驱动的遗留系统改造 。不同于面向标准的 backlog 工作,在这一方法下,团队提出可度量的预期技术成果,并共同建立一组对问题的假设。然后,团队根据优先级在有限时长内进行迭代试验,来验证或推翻每个假设。由此将产生优化后的工作流程,这一流程不是为了按照计划朝着可预测的结果前进,而是为了减少不确定性。

    历史信息
  • 随着组织朝着演进式架构的方向发展,记录下围绕设计、架构、技术和团队工作方式的决策是非常重要的。收集和汇总那些会导致这些决策的反馈的过程从RFCs(Request for Comments )开始。RFCs 是一种用于收集上下文、设计和架构思想,并与团队协作,最终达成决策以及上下文和结果的技术。我们建议组织采用一种 轻量级的 RFCs 方法 ,通过在多个团队中使用简单的标准化模板和版本控制来获取 RFCs。

    当未来的团队成员回过头来重新审视这些决策时,掌握这些信息将使他们受益无穷,与此同时记录组织的技术和业务的发展也十分重要。成熟的组织已经在自治团队中,特别是在跨团队相关的决策中使用 RFCs 来推动更好的沟通和协作。

    历史信息
  • 所有主流的云厂商都提供了令人眼花缭乱的机器学习解决方案。这些强大的工具虽然可以为用户提供很多价值,但同时也意味着一定的开销:云厂商收取的除了基本的服务运行成本外, 还包含一些营业税。 这些复杂的工具需要被使用者理解和操作,随着架构中新工具的添加,税也会随之水涨船高。 根据我们的经验,很多团队之所以会选择复杂的工具,常常是因为他们低估了诸如线性回归之类的简单工具的力量。 其实,许多机器学习问题并不需要GPU或神经网络。 因此,我们提倡在现有的计算平台上使用简单的工具和模型,以及少量的Python代码来实现一个 最简单的机器学习 。 只有在能够证明它的必要性时,才使用这些复杂的工具。

    历史信息
  • 绞杀榕模式常被用作遗留系统现代化改造的默认策略,这种策略下,新代码包围在旧代码周围,并慢慢地实现旧代码的能力来满足所需功能。这种“由外而内”的方式对于很多遗留系统非常有用,但现在我们有了更多单页应用(SPA)的经验,可以用它们来替换遗留系统,我们正使用相反的“从内到外“的方式来替换遗留系统。与包围遗留系统不同,我们向旧应用HTML文档嵌入新的单页应用,并基于此逐渐扩展功能。只要用户能够容忍由于页面大小增加而带来的性能问题,新单页应用的框架就不需要与原有框架保持一致(例如,向原有的AngularJS应用嵌入新的React应用)。 单页应用注入 允许你逐渐迭代掉旧的单页应用,直到它被新应用完全替代掉。与绞杀榕模式通过在已有稳定代码的基础上构建新代码并最终替换旧代码相比,这种方式更接近于向已有应用注入一个外部的代理并依赖原有单页应用的功能,直到新应用能够完全接管。

    历史信息
  • 系统的架构反映了组织架构和沟通机制。我们应当有意识地关注团队如何互动,这并不是什么大新闻,正如康威逆定律 (Inverse Conway Maneuver)所描述的那样,团队的互动是影响团队向客户交付价值的速度和容易程度的重要因素。我们很高兴找到一种方法来衡量这些互动。我们使用组织架构和高效团队 (Team Topologies)的作者提供的评估方法。这种评估方法可以让你理解团队构建、测试和维护其服务的难易程度。通过衡量 团队的认知负担 ,我们能够为客户提供更好的建议,帮助他们改变团队架构,改进团队的互动方式。

    历史信息
  • 许多使用 Xcode 编写 iOS 代码的开发者经常会因为 Xcodeproj 文件总是随着项目配置变化而变化而头痛不已。由于Xcodeproj 文件格式难以阅读,因此合并文件冲突非常复杂,有可能导致生产力下降甚至打乱整个项目,因为这个文件一旦出现错误,Xcode 将无法正常运行,开发工作也很可能被迫中断。因此,我们建议不要手动合并修复 Xcodeproj文件,或是对其进行版本管理,而是 使用工具管理 Xcodeproj : 用 YAML(XcodeGenStruct),Ruby(Xcake)或是 Swift(Tuist)定义你的Xcode项目配置。这些工具会根据配置文件和项目结构生成 Xcodeproj 文件,因此, Xcodeproj 文件合并冲突将成为历史,相比之下配置文件冲突要容易处理得多。

    历史信息
  • 随着TypeScript成为前端开发的常用语言以及Node.js成为BFF的首选技术,我们看到 “UI/BFF共享类型”正在被越来越多地使用 。在这种技术中,一个类型定义不仅会被使用在前端请求返回的数据中,也会被使用在服务端用来满足这些查询。由于这种做法会跨越流程边界产生不必要的紧密耦合,因此我们通常会对这种做法保持谨慎。但是,许多团队发现这种方法的好处胜过耦合带来的风险。当一个团队同时拥有UI和BFF代码时,通常会将组件存在同一个代码库中,这个时候BFF模式是最有效的,因此UI / BFF对可以被看作是一个单一的内聚系统。当BFF提供强类型的查询时,可以针对前端的特定需求量身定制查询结果,而不必重用一个通用的实体,因为这些通用实体需要为很多消费者服务因此会包含很多不必要的字段。这样可以减少意外地将不必要的数据暴露给用户的风险,防止对返回的数据对象进行错误的解释,并使查询更加表意。当使用io-ts来增强运行时类型安全性时, 这种实践特别有用。

    历史信息

评估?

  • 现在很多公司正在面临的一个最微妙的决定便是是否要采纳低代码平台或无代码平台,这些平台可以被用来在非常特定的领域里解决一些特定的问题。限界低代码平台这一领域的供应商也有如过江之鲫。现在看来,这类平台的一个突出的问题,便是很难应用一些诸如版本控制之类的优秀的工程实践。而且这类平台上的测试也非常的困难。然而我们还是注意到了这个市场里的一些有趣的新兵,例如 Amazon Honeycode 可以被用来创建一些简单的任务和事件管理应用,还有 IFTTT(类似于云工作流)领域的 Parabola,这也是为何我们会将 限界低代码平台 纳入这个部分的原因。但是我们仍然对它们更广泛的适用性深表怀疑,因为这些工具,如日本 Knotweed,非常容易超出它们原本的限界而被泛化用于其他场景,这也是为什么我们对采纳这种技术持强烈的谨慎态度。

    历史信息
  • SSL/TLS 的核心贡献者 Christopher Allen 在2016年给我们介绍了一种用于支撑新型数字化身份的10个原则,以及实现这一目标的途径:通往自主身份之路。自主身份也被称为 去中心化身份 ,按照基于IP协议栈的信任标准,是一种“不依赖任何中心化权威并且永远不能被剥夺的任何人、组织或事物的终身可转移身份”。采纳和实现去中心化身份正在逐渐升温并变得可能。我们看到了它在隐私方面的应用:客户健康应用政府医疗基础设施公司法律身份。如果想快速地应用去中心化身份,你可以评估 Sovrin NetworkHyperledger AriesIndy 等开源软件,以及去中心化身份可验证凭证 标准。我们正在密切关注这个领域,并帮助我们的客户在数字信任的新时代进行战略定位。

    历史信息
  • 部署漂移提示器 使得部署在多个环境中的软件版本漂移能够被可视化。使用了自动部署方式的组织在将软件部署到接近生产环境的环境中时,可能需要人工批准,这就意味着这些环境里的代码版本可能比当前的开发版本落后好几个版本。这项技术使得这些延后能够被展示在一个简单的面板内,包括在每个环境当中,每个被部署的组件有多大程度的延后。这能够帮助突出由于已经完成的软件没有部署到生产环境而导致的机会成本,并使得团队注意相关的风险,例如尚未部署的安全修复。

    历史信息
  • 完全的同态加密 (HE)是指一类允许在加密数据上直接进行计算操作(如搜索和算数运算)的加密方法。同时计算的结果仍然以加密的形式存在,并且稍后可以对其进行解密和显示。虽然同态加密问题早在1978年就被提出来了,但直到2009年才出现解决方案。随着计算机算力的提升,和诸如SEAL, Lattigo, HElibPython中的部分同态加密之类易于使用的开源库的出现,同态加密在现实世界的应用程序中的应用才真正地变得可行。那些令人振奋的应用场景包括在将计算外包给一个不受信的第三方时的隐私保护,例如在云端对加密数据进行计算,或使第三方能够聚合同态加密后的联邦机器学习的中间结果。此外,大多数的同态加密方案被认为是对量子计算机安全的,并且标准化 同态加密的努力也正在进行之中。尽管同态加密目前在性能和可支持的计算类型上还存在诸多局限,但是它仍然是一个值得引起我们注意的技术。

    历史信息
  • Hotwire (跨端传送HTML)是一项构建网页应用的技术。页面由组件组成,然而与现代单页应用不同,这些组件的HTML在服务端生成并“跨端”传送至浏览器。这样的应用只在浏览器端运行少量的JavaScript代码用以将HTML片段组合在一起。包括我们在内的许多团队在异步web请求获得跨浏览器支持的2005年前后都尝试了这项技术,然而由于各种原因,这项技术并未引起很多注意。 如今,Hotwire使用现代网页浏览器和HTTP的能力来实现单页应用(SPA)的快速、自适应和动态特性。它通过将逻辑放在服务端并保持客户端代码的简洁,实现了更简单的网页应用设计。Basecamp团队发布了一些Hotwire框架来支持他们自己的应用程序,其中包括TurboStimulus。Turbo包含了提升应用程序响应速度的一系列技术和框架,例如防止整个页面重新加载、从缓存预览页面以及根据请求将页面切片等。Stimulus旨在通过将JavaScript对象与HTML页面元素关联起来,以增强浏览器当中的静态HTML。

    历史信息
  • 当使用多个 微前端来组建应用程序时,系统的某些部分需要确定加载哪些微前端以及从哪里加载它们。一直以来,我们要么通过构建定制化解决方案,要么采用single-spa之类的热门框架来解决这个问题。最近出现了一个新标准模块映射,它对这两种方案都有所助益。我们的初步经验表明,使用 微前端中的模块映射 可以清晰地分离关注点。它使用JavaScript代码说明要导入的内容,同时在初始化HTML的响应中使用一个轻量脚本指定从哪里加载微前端。 显然,HTML是在服务器端生成的,这样在渲染过程中就可以使用一些动态配置。在许多方面,这种技术让我们想起了动态Unix库的linker/loader目录。目前,只有Chrome浏览器支持模块映射,但是通过SystemJS polyfill就可以使它得到更加广泛的应用。

    历史信息
  • 开放应用程序模型 (OAM) 旨在为“基础设施即软件”制定标准化方案。利用组件、应用程序配置、范围和特征等抽象,开发人员能以与平台无关的方式描述其应用程序。而平台实现者则完全可以用工作负载、特征和范围等另一套抽象来定义其平台。自从上次提到 OAM 以来,我们一直对其首个实现 KubeVela 保持着关注。 如今 KubeVela 即将发布1.0版,我们期待着它能证明 OAM 构想中的前景。

    历史信息
  • 关注隐私的网络分析 是一种收集网络分析的技术,它通过对终端用户匿名化的处理而防止泄漏其隐私信息。遵守通用数据保护条例(GDPR)的一个令人惊讶的结果是,许多组织不惜降低用户体验地使用复杂的cookie同意过程,尤其是在用户没有立即同意“所有cookies”的默认设置的情况下。关注隐私的网络分析具有双重优势,无论是形式还是实际它都遵守了GDPR条例,与此同时也避免了引入具有侵入性的Cookie同意书。这项技术的一个实现便是Plausible

    历史信息
  • Mob编程是我们团队发现的一项能使远程工作变得更加方便且容易的技术。 远程 mob 编程 允许团队成员快速“蜂拥”在一个问题或者一小段代码周围,不用受物理限制而需要找到一个可以容纳多人的房间。团队可以在一个问题或者一段代码进行快速地协作,而无需连接到一个大型显示器,预定会议室或者找一个白板。

    历史信息
  • 安全多方计算 (MPC) 解决了多方隐私保护的协作计算中,各方互相不信任的问题。其目的是在无可信第三方的情况下,安全地计算出一个商定的问题。计算时,每个参与者都必须参与结果计算,并且不能被其他参与者获得计算结果。安全多方计算的一个简单例子是百万富翁问题:两个百万富翁想了解谁是最富有的人,但又不想透露给彼此他们的实际净资产,同时他们也都不信任第三方。安全多方计算的实施方法各不相同,可能包括秘密共享,遗忘传输,混淆电路或同态加密。最近出现的一些商业安全多方计算解决方案(例如Antchain Morse)声称有助于解决诸如多方联合信用调查和病历数据交换等情形下,秘密共享和安全机器学习的问题。尽管从市场营销的角度来看,这些平台很有吸引力,但它们是否真的有用仍拭目以待。

    历史信息

暂缓?

  • 我们建议在采用 GitOps 时一定要谨慎,尤其是在分支策略方面。GitOps可以被视作一种基础设施即代码的实现方式,这种方式持续地从Git同步基础设施代码,并将其部署到多个环境当中。在为每个环境创建一个分支的场景下,对基础设施的修改会通过合并代码的方式从一个环境应用到下一个环境。诚然,将代码作为基础设施修改的唯一来源,是一种合理的方式,但我们发现对每个环境创建分支会导致环境之间的不一致。最终,合并特定环境的配置代码带来了许多问题,甚至导致这种方式被废弃。这与我们之前在Gitflow的长期分支当中看到的情景非常相似。

    历史信息
  • 软件平台的流行为组织创造了很多价值,但是在构建基于平台的交付模型的道路上到处都是潜在的死胡同。在这些新流行技术的刺激下,我们往往会发现它们实际上都是“新瓶装旧酒”,是“老技术”在新时代背景下的另一种“复兴”,这很容易使我们忽略一开始选择放弃这些技术的原因。我们在上一期的技术雷达中发表的 披着API网关外衣的企业服务总线 就是一个很好的例子。我们看到的另一个例子是“按技术层级划分团队”,只不过换了个说法将其称为平台。在构建应用程序的上下文中,前端团队,业务逻辑团队和数据团队分开是很常见的,而在组织根据平台能力划分业务或数据层团队时我们看到了与之相似的模型结构。由于康威定律,我们知道围绕 业务能力 组织平台功能团队是一种更有效的方式,它为团队提供能力的端到端的所有权,包括数据所有权。这有助于避免 分层的平台团队 的依赖管理问题,否则做任何事情的时候前端团队都必须依赖业务逻辑团队,而业务逻辑团队又必须依赖数据团队。

    历史信息
  • 密码策略是当前很多组织会默认启用的标准。然而,我们仍然见到很多组织内部要求密码必须包含符号、数字、大小写字母和特殊字符。诸如这样的要求就是 天真的密码复杂度要求 。这些要求会导致错误的安全意识,因为用户会由于满足这些要求的密码太难以记忆和输入,而选择使用更不安全的密码。正如NIST(美国国家标准技术研究所)推荐所提到的,影响密码强度的主要因素是密码的长度,因此用户应该选择更长的密码,最长为64个字符(包括空格)。这些密码会更安全,并且更易于记忆。

    历史信息
  • 一些组织似乎觉得 代码同行评审等同于pull request 。他们认为唯一能够实现代码评审的方法就是pull request。我们发现这种方法会造成严重的团队瓶颈,并且显著地降低反馈的质量,因为超负荷的评审人员会开始简单地拒绝pull requests。虽然有观点认为,这是一种展示代码评审强制性的方式,但是我们的一个客户被告知,这种观点没有任何的依据,因为没有证据能够表明代码在被接受之前真的有被阅读过。Pull requests只是管理代码评审工作流的一种方式,我们敦促人们考虑其它的方法,特别是在需要对代码提供指导和反馈的情况下。

    历史信息
  • 我们对“做敏捷之前先得变得敏捷”的定位以及我们对该主题的观点应该不会让人感到意外。根据Gartner 2019年5月的报告来看,规模化敏捷框架® (Scaled Agile Framework®)是被考虑和使用得最多的企业敏捷框架,我们也看到越来越多的企业正在经历组织变革,因此我们认为是时候再次提高对该主题的认知了。我们遇到过一些组织在过度标准化的规模化敏捷框架(SAFe)和阶段化流程中苦苦挣扎。这些流程在组织架构及其运作模式中造成摩擦。它还会导致组织中形成孤岛,阻碍平台成为真正的业务能力推动者。自上而下的管控会在价值流中产生浪费,阻碍工程人才的创造力,同时限制团队的自主性和试验。相较于衡量工作量并关注标准化的仪式,我们更加推荐采用一种更精益的,以价值驱动的方法和治理来帮助组织减少摩擦,例如价值驱动的数字化转型或者团队认知负荷评估,以识别团队的类型并确定他们应该如何更好地互动。

    Scaled Agile Framework® 和SAFe™均为Scaled Agile公司的商标。

    历史信息
  • 理想情况下,尤其是当团队实践DevOps时,流水线和被部署的代码应该由同一个团队所有。遗憾的是,我们仍然可以看到 代码与流水线的所有权分离 的团队:他们的流水线由基础设施团队所有,这会导致变更延迟、改进受阻以及开发团队缺乏对部署的所有权和参与度。造成这种情况的一个原因显然是团队分离,另一个原因可能是想要保留审核的流程和“守门员”的角色。尽管使用这种方式(例如:监管控制)可能有比较合理的解释,但总的来说,我们发现它令人不悦并且收效甚微。

    历史信息
  • 平台化的终极目标之一便是将基于工单的流程降到最低,因为这些流程会在价值流中形成队列。遗憾的是,我们仍然看到一些组织在这一目标的推进上做得不够有力,并因此导致了 工单驱动的平台运营模式 。尤其是当这些平台化服务是构建于一些自服务的和API驱动的公有云服务之上时,这一情况便格外令人沮丧。虽然从一开始就实现自服务且不依赖于工单是很困难且没有必要的,但必须明确的是,这应该是我们努力的目标。 对官僚主义的过度依赖和信任的缺失是组织在面对这种基于工单的流程却不愿做出改变的原因之一。在平台中加入更多的自动化校验和告警是帮助我们从工单审批流程中抽身的一种方法。例如给团队提供运行成本的可见性,并设置自动化的成本护栏以避免意外的成本激增。通过实现安全策略即代码,使用配置扫描器 或类似Recommender的分析工具,来帮助团队做正确的事。

    历史信息
无法找到需要的信息?

每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

新的,移进/移出 ,没有变化