默认值必须好用
如果一个功能需要读完 30 页文档才能用起来,那就是设计失败。我们的每个默认配置都以「不配置也能跑」为标准。
我们不做大而全的云,也不做又一个应用框架。我们花了五年时间,把环境、发布、回滚、监控和告警这些没人愿意重复写的部分做成默认能力。
2020 年春天,三位创始人在上一家公司负责基础架构。同一个季度里,他们帮四个不同的业务小组搭了四套几乎一样的 CI/CD: 一样的镜像仓库、一样的日志收集、一样的告警规则,只是名字不同。
既然这件事每个团队都要做一遍,那就应该有人把它做成产品。当年 6 月,公司在深圳南山成立,第一版 Deploy 内测上线, 首批 40 个团队来自创始人的朋友圈——大部分是只有两三个人的创业公司。
五年过去,我们仍然只做这一件事,只是范围从「部署」扩展到了「部署 — 流水线 — 观测」的完整链路。 今天的我们服务着 26000 支团队,其中绝大多数从未与我们的人说过一句话——这正是我们想要的状态。
深圳南山
名同事,分布在深圳、成都与杭州
不做电商、不做硬件、不做咨询交付。公司的收入只来自平台订阅与用量计费, 所以我们唯一需要讨好的人,是每天要按下发布键的那位工程师。
下面六个节点里,只有第一个是计划内的。其余五个都来自用户反馈:有人提了,我们发现不止一个人需要,才决定做。
6 月在深圳南山注册成立,第一版一键部署上线。首批 40 个团队里,有 31 个至今仍在使用我们的平台。
起因是一位用户抱怨「后端改个接口,前端要等一整天」。我们把按分支生成临时环境做成默认行为,联调周期平均缩短 60%。
发布变快之后,问题变成了「发布完不知道有没有变坏」。Lens 把日志、指标与链路追踪带上,并把发布记录对齐到同一时间轴。
为满足出海团队与跨境业务需求,香港区域开放,同时把控制台、文档与 CLI 全部做了中英双语。
插件市场开放,社区提交了 540 份贡献,覆盖构建插件、脚手架模板与文档翻译。
新增测试覆盖率门禁、构建产物签名校验与私有构建集群,让有合规要求的团队也能用同一套流程。
这四条不是口号。每一条都能对应到具体的产品行为,也都能在需求评审时用来否决一个提案。
如果一个功能需要读完 30 页文档才能用起来,那就是设计失败。我们的每个默认配置都以「不配置也能跑」为标准。
只使用 Docker、OCI、OpenTelemetry 这类开放标准。任何时候你都能把配置、镜像与数据整体拿走,我们不加迁移门槛。
每个新功能上线前都要写清成功指标:构建时长、发布频率、恢复时间或告警噪音量。三个月后达不到就下线。
不读取业务代码内容,不用于模型训练,不做二次分发。这条写进了合同,也写进了每位新同事的入职第一课。
公司没有专职的「需求转述层」。四位负责人都还在提交代码或直接读用户工单,产品决策在周会上当面争论完就执行。
创始人 & CEO
此前在云厂商负责基础架构,做过 12 年分布式存储与调度系统。相信「基础设施的价值等于它被忘记的速度」。
联合创始人 & CTO
编译器与构建系统出身,负责流水线引擎与远程缓存。构建时长从 88 秒降到 38 秒的主要工作由她推动。
产品负责人
从一线研发转做产品,主导了预览环境与发布看护两个功能。每周固定读 30 条工单原文,不做摘要。
开发者关系负责人
维护 CLI、插件市场与 540 位社区贡献者的对接工作。公司开源仓库的 issue 平均响应时间由他盯着。
每一次部署背后都有一个正在等着上线的团队。平台每多停一分钟,就有人要多熬一个小时。
支团队把发布交给了我们
次,其中约 62% 来自预览环境
位开发者提交过插件、模板或文档
中位数,较 2022 年下降 57%
我们不设前台接待流程,也不安排销售环节。来了通常就是和工程师一起看你的流水线日志。
南山区科技园科苑路 15 号方格大厦 8 层
邮编 518057 · 0755-8888-2020
高新区天府五街 200 号 3 号楼 11 层
邮编 610041 · 主要负责流水线引擎
余杭区文一西路 969 号 6 层
邮编 310000 · 主要负责华东客户支持
常年招聘后端工程师(构建与调度方向)、前端工程师(控制台与可视化)、以及开发者关系工程师。远程岗位占三分之一,深圳与成都也有工位。
把简历发到 hi@gridbox.dev,标题注明「应聘 + 岗位名称」。我们会在 3 个工作日内回复,无论结果如何。