服务 · 05

云与运维

系统稳定运行,出了问题,您比客户先知道

您的系统放在您自己的云账户里,每次都用同样的方式上线,监控足够周密,故障先找到负责的人,而不是先落到客户头上。

平淡无奇,正是目标。

企业赖以运转的系统,通常是在没人决定该放在哪里的情况下,自己长出来的。一个跑在桌子底下的电脑上,一个跑在前员工搭的服务器上,一个跑在用某人私人信用卡付费的主机账户上。没有人确定:如果那台机器在周日坏了会怎样,备份有没有真正恢复过,上个月的账单为什么涨了。

这项工作就是让这一块变得平淡无奇。一切都运行在以贵公司名义开设的账户里;配置以文件的形式写下来,而不是靠某个人记住的步骤;上线一个改动,团队里任何人每次都能用同样的方式完成,也能用同样的方式撤回;系统有足够周密的监控,故障在落到客户头上之前,先找到指定的人。我们按您企业的实际规模来配置,而不是照着大公司乐于画出来的架构图。

团队
指定负责人,贯穿整个项目
运行于
您自己的账户,从第一天起
定价
固定价格,按里程碑收费;首次通话后提供逐项列明的固定报价

适合

  • 一个没人敢在周五上线的系统
  • 一切都依赖某一台笔记本电脑,或某一家供应商
  • 一张没人能逐行解释的云账单

您会得到

  • 每个账户、域名和密钥,从第一天起都在您自己名下
  • 团队里任何人都能用同样的方式发布,也能用同样的方式撤回
  • 告警送到指定的人手里,并写明该怎么处理
  • 开发前就书面告诉您的每月成本
如何进行

四道关口。每一道都由您验收之后,下一道才开始。

与每一个项目相同的四道关口,这里是它们在这类工作中的具体样子。

诊断

我们写下您在运行什么,每一部分放在哪里,谁掌握着钥匙,以及其中任何一个停下来会发生什么。诊断报告按停机会给您造成的损失对这些风险排序,并指出哪些可以在一天之内消除。

验证

先按新方式迁移或重建一个系统,整套配置都写成文件,备份要真正恢复一次,而不是想当然。运行成本与实际账单核对,两个数字都写下来。

开发

其余部分每两周推进一次,都在您自己的账户里完成。发布变成可撤回的例行工作,告警开始送到人手里,旁边写着该怎么处理,每月成本则对照我们当初说的数字复核。

交接

趁我们仍随时待命,由您的团队来运行:怎么发布,怎么回滚,半夜的告警发给谁、他该怎么做。复盘会写明哪些现在已经安全,哪些仍是单点故障,以及要消除它需要做什么。

案例

40 家研究中心,患者数据只录一次,每次修改都有记录。

一家在 40 家医院研究中心开展试验的研究机构。数据通过纸张和电子邮件传来,核对一条记录要追着三个人跑。

节省时间 · 临床研究 · 海得拉巴
11 天变为2 天

从发出质疑到关闭质疑

从监查员发出质疑,到研究中心解决为止

研究中心录入的生命体征表单,数值一填入就触发核查:一个超出预期范围的血压值,一个不可能晚于访视日期的日期,一个空着的必填项;旁边是未关闭的质疑数,以及记录谁在何时改了什么的稽查轨迹。
根据文中描述绘制的界面示意图,并非截图。
我们还约定测量的其他指标
  • 每录入 100 个字段发出的数据质疑数监查员退回研究中心要求更正的字段
  • 稽查轨迹有缺口的记录修改没有记录修改人、修改原因或原值
阅读案例: 40 家研究中心,患者数据只录一次,每次修改都有记录。
老板们常问的问题

老板们在打电话之前会问的问题。

我们的系统究竟应该放在哪里运行?

放在以贵公司名义开设的账户里,由您的财务团队直接付账,服务商就选您的团队用得惯的那家。除此之外,诚实的答案通常比人们预想的要简单:用别人负责打补丁的托管服务,而不是需要您自己照看的机器。怎么决定,取决于您的客户在哪里,出于合规要求哪些东西必须留在印度境内,以及您的团队在凌晨 3 点能撑得住什么。如果答案是一台普通服务器而不是一整套平台,我们会告诉您。

我们的云账单一直在涨,却没人说得清原因,这正常吗?

很常见,也能解决。账单上涨,往往是因为资源没有标注,测试系统一直开着没关,存储从不清理,或者某样东西是按一次始终没有到来的上线高峰来配置的。第一步是让账单上的每一行都能对应到一个系统和一个负责人,通常第一轮梳理就能砍掉账单中明显的一部分。之后每月对照我们当初说的数字复核成本,费用一有跳涨就触发告警,而不是到年底才吓一跳。

如果系统半夜宕机,怎么办?

告警会发到指定的人的手机上,旁边写着坏了什么、该怎么处理。有人盯着的系统和只能靠祈祷的系统,区别就在这里。哪些故障值得把人叫醒,由我们和您一起约定,因为什么都报警的告警,最后没人会看。项目期间,名单上有一位创始人;交接后换成您的团队,书面处理办法放在您自己的账户里;如果您希望我们继续盯着,可以选择按月维护服务。

我们怎么知道备份真的管用?

因为我们会按计划当着您的面恢复一次,并把所用的时间写下来。从没恢复过的备份只是一种信念,而不是保障:常见的发现是,有一个数据库从来没被纳入备份;恢复所需的时间比任何人以为的都长得多;或者根本没人有启动恢复所需的凭证。我们和您约定两个朴素的数字:最多能承受丢失多少数据,最多能承受停机多久,然后按这两个数字来测试,而不是按一句承诺。

别人做的系统,你们能接手吗?

通常可以。第一步是弄清楚现在到底有什么:有哪些账户,谁掌握着钥匙,哪些东西在运行、却没人记得是谁启动的。无论您是否继续与我们合作,这份清单都会以文档形式交给您。前一位开发者没留文档的地方,我们边做边补写;确实无药可救的,我们会直说,并说明替换它需要做什么,而不是一直收费帮您勉强撑着。

我们需要自己的服务器,还是租用就够了?

对几乎所有这个规模的企业来说,租用就够了,自己买反而分散精力:有了自己的机器,公司里就得有人负责供电、散热、备件,以及没人喜欢的打补丁。只有在少数情况下,买才划算:比如长期稳定的重负载,租金一直降不下来;或者有规定要求数据必须放在您自己掌控的硬件上。在任何人签字之前,我们会按您的业务量用真实数字算清楚,并把对比结果写下来。

给您的技术顾问

基础设施即代码、可复现的环境、CI/CD、可观测性,以及真正经过测试的备份恢复。规模与业务相称:先用托管服务,再考虑集群;除非负载确实需要,否则不上 Kubernetes。

  • 基础设施即代码,存放在您的代码仓库中,没有只能在控制台里操作的资源
  • 支持回滚的 CI/CD 流水线,归您的团队所有
  • 监控看板、告警路由和值班运维手册
  • 恢复演练结果,以及成文的恢复目标

技术栈 Terraform · Docker · GitHub Actions · AWS · Azure · GCP · Grafana · OpenTelemetry

延伸阅读

运行成本表也是交付物

为什么系统的持续运行成本,要在开发前约定,而不是之后。

开始

写一段话。创始人会在 1 个工作日内回复。

随后是与两位创始人的 30 分钟通话。不放幻灯片,也不套方案模板,只是先初步判断:我们是否适合解决这个问题。

也可以通过邮件、电话或 WhatsApp 联系: hello@netogrit.com · +91 94330 54299 · WhatsApp(在新标签页中打开)