DevOps 与云基础设施

托管式 DevOps 与运维

为你的软件在上线之后配备一支负责到底的团队，而不只是做一次交接。我们在与你商定的支持计划下运行发布、监控、事件处理、补丁更新、备份测试与报告。

沟通您的项目洽谈托管运维

上线正是运维的起点

上线软件需要持续的照料：依赖会老化，证书会过期，流量会变化，而备份只有在能够恢复时才有意义。托管 DevOps 与运维为这些工作提供一个负责到底的负责人。我们运行受控发布，关注监控与告警，在约定时间内处理事件，应用补丁，测试恢复，审查访问权限，并就性能与成本进行报告。它既适用于我们构建的软件，也适用于并非我们构建的应用，包括用 AI 工具构建的应用。每次合作都从一次入驻审查开始。

AI 辅助运维，变更由人工批准

AI 如何协助

  • 在工程师调查的同时，关联告警、日志和近期部署以提出可能的原因。
  • 对补丁级别、依赖、证书过期、备份结果和配置漂移进行例行检查。
  • 总结依赖的发布说明，在安排更新之前标记出破坏性变更。
  • 根据监控数据起草事件时间线、变更说明和定期报告。

我们的专家负责什么

  • 事件决策：严重程度、回滚还是修复，以及告知你的团队和用户什么。
  • 对每一次生产变更的批准。智能体不会获得不受限制的生产访问权限。
  • 恢复测试：由工程师执行还原，并确认数据和服务确实能够恢复。
  • 支持计划：涵盖的时段、响应承诺和排除项，均提前与你商定。

当告警触发时会发生什么

涵盖时段内的典型事件处理路径；严重程度级别、联系人和响应承诺来自您的支持计划。

  1. 告警

    监控捕捉到用户会注意到的症状，例如错误、页面缓慢或作业失败。

  2. 分诊

    工程师确认受影响的范围和广度，由 AI 汇总近期变更和相关错误。

    检查点: 由工程师设定严重程度

  3. 缓解

    先止损：回滚、关闭某个功能开关或增加容量，在查明原因之前就先行处理。

    检查点: 每一项生产操作都由工程师批准

  4. 沟通

    您的指定联系人会收到有关影响、当前行动以及下一次更新预期时间的进展通报。

    检查点: 面向您用户的措辞会与您商定

  5. 修复

    在代码或配置中修复根本原因，在预发布环境中测试，并通过流水线发布。

  6. 事件后复盘

    一份不追责的书面记录，说明原因、时间线以及监控遗漏了什么；后续事项会加入改进清单。

    检查点: 后续优先级会与您商定

当出现故障时: 如果某项缓解措施未能持续奏效，或原因出在第三方，我们会按您的支持计划所规定的方式升级，并持续通报进展。

我们管理的内容

持续的责任，而非一次性的交接

  • 受控发布

    通过经过审查的流水线进行有计划的部署，附带发布说明、在合适时采用分阶段发布，并在每次发布前检查回滚路径。

  • 监控与告警

    对可用性、错误、性能和资源进行持续的自动化监控，并将告警发送给你支持计划中指定的人员。

  • 事件处理

    在涵盖时段内进行分级、修复或回滚，并提供清晰的进度更新，随后就原因和后续工作提供书面审查。

  • 补丁与依赖更新

    按计划进行操作系统、运行时、库和证书更新，在上生产前经过测试，并优先处理紧急的安全修复。

  • 备份与恢复测试

    定期验证备份并演练还原，使恢复步骤在你需要之前就已在实践中得到验证。

  • 审查与定期报告

    访问权限审查、性能与成本可见性，以及关于事件、变更、风险和建议后续步骤的定期报告。

谁会把运维交给我们

运维总是输给功能开发：告警无人查看、更新一拖再拖等着某个清闲的周，一旦宕机就变成四处寻找还有谁持有访问权限。

  • 其启动代理机构或原始开发者早已离场的创始人
  • 没有 DevOps 专才的产品团队，宕机只能由开发者自己处理
  • 依赖某个营收关键的 Web 应用、却无人主动维护的企业

典型的运维请求

我们所界定范围的典型场景，而非客户案例研究。

  • 承包商离开时带走了唯一的访问权限

    负责运行服务器的承包商即将离开，而交接只是一通电话。我们会列出他们持有的每一个登录凭据和密钥，予以轮换，确认备份可以恢复，并在他们离开之前写清楚什么在哪里运行。

  • 某个运行时即将终止支持

    产品运行在一个即将停止接收安全更新的语言运行时上。我们会分阶段规划升级，在预发布环境中针对您的关键工作流测试每个阶段，并在约定的维护窗口内发布。

  • 所有人都已学会忽视的告警

    团队收到的告警太多，以至于真正的问题淹没在噪音里。我们会检查哪些告警导致了行动，合并或停用其余的，并把剩下的按严重程度路由给支持计划指定的人。

托管运维如何启动

  1. 01

    入驻审查

    我们审查代码、基础设施、访问权限、备份、监控和已知风险，包括并非我们构建的软件，并商定优先修复哪些。

  2. 02

    商定支持计划

    以书面形式明确涵盖的系统、支持时段、响应承诺、升级联系人、双方责任和排除项。

  3. 03

    稳固基础要素

    补齐缺失的监控、备份、访问控制和运行手册，并在例行运维开始前修复紧急风险。

  4. 04

    运行与报告

    发布、监控、补丁更新、恢复测试和审查按计划运行，附带定期报告和一份商定的改进清单。

使用 AI 工具的两种方式

AI 协助处理基础设施代码和诊断。选择它可以在何处处理您的配置和日志。

不确定？我们会在界定范围时为您推荐一个。 比较 AI 交付选项

托管运维计划之外的内容

  • 超出您支持计划所含改进工作范围的新功能，将作为开发项目单独界定范围。
  • 我们尚未入驻的系统，例如某个供应商的平台或未经审查的服务器，在它们经过审查并纳入之前仍不在计划范围内。
  • 对安全入侵事件的取证调查不包含在内。在计划范围内，我们会遏制事件、保全日志并支持负责调查的人员。
  • 第三方服务（如支付、邮件或模型 API 提供商）的中断不在我们的控制范围内；我们会监视它们，并在设计允许的情况下绕过它们继续运作。

开发、QA 与 AI 运维如何衔接

  • 来自同一团队的修复

    当监控或某次事件指向代码问题时，我们的工程师可以在合作范围内进行修复，或将清晰的诊断交给你的开发人员。

  • QA 回归覆盖

    补丁、依赖更新和修复在发布前都会经过回归测试，使例行维护能够对照你的重要工作流进行检查。

  • AI 智能体与模型运维

    如果你的产品使用 AI 功能或智能体，我们会加入评估、提示词与模型更新以及权限审查。托管私有模型由 Private AI Infrastructure 负责。

  • 持续改进

    报告会转化为一份按优先级排列的性能、成本、安全和路线图工作清单，与你一起排期，而不是留在一份文档里。

常见问题

常见问题解答

如果在工作时间之外出现故障会怎样？

监控和告警持续运行。谁在非工作时间响应、以及响应速度如何，由您的支持计划确定：涵盖的时段、按严重程度划分的响应承诺、升级联系人和例外情况。如果关键系统需要非工作时间的覆盖，我们会明确界定并达成一致，而不是想当然地假定。

你们能管理一个不是你们开发的应用吗？

可以，包括使用 AI 工具构建的应用。我们首先对代码、基础设施、访问权限、备份和监控进行入驻审查，然后在接手日常运维之前先修复最紧迫的风险。如果某些东西按现状无法安全运行，我们会告知您并提出变更建议。

一个支持计划包含哪些内容？

涵盖的系统、支持时段、按严重程度划分的响应承诺、升级联系人、维护窗口、报告周期、双方的责任以及例外情况。它还规定了包含多少改进工作。我们会在入驻审查之后达成一致，以便它反映实际需要运行的内容。

AI 工具会看到我们的日志和生产数据吗？

只会看到您所允许的内容。访问遵循最小权限原则，AI 工具基于约定的日志、指标和配置工作，并将密钥排除在外。如果这些资料必须留在您的边界之内，私有 / 本地 AI 工程会使用部署在您控制的基础设施或约定的隔离环境中的模型。Claude Code / OpenAI Codex 工程则在约定的账户和数据保留设置下使用商业代理。

相关阅读

为您的在线软件配备一支负责到底的团队

告诉我们正在运行什么，以及您担心什么。我们会从入驻审查开始，并提出一个契合的支持计划。

沟通您的项目从一次审查开始