1. 通信协议的选择
运维系统更适合 HTTP 而非 gRpc 。熟悉 HTTP 的运维、研发人员比其他协议的人多。在掌握 HTTP 协议的基础上，学习 Restful 风格的 HTTP API 很快。更多人熟悉、更易于学习，意味着更好沟通、更低的交接成本，因为他们有着更多共同的领域背景。支持 HTTP 调试的工具非常多。无论是浏览器，还是各种插件，命令行工具，都可以很方便地调试接口。系统集成方便。运维人员擅长的是 Shell、Python 等脚本语言，调用一个 HTTP 接口很容易，而不用生成 gRPC Client 进行编程。系统集成的成本低意味着你提供的服务会得到更多使用。对于运维系统来说，清晰、简单、兼容性好的通信协议更加重要，而不必强调性能，这与业务系统有着显著差异。
2. 集中还是分散管理数据
运维系统更适合集中管理数据，而非分散管理数据。可以将运维系统认为是整个公司系统的控制平面，而业务系统认为是整个公司系统的数据平面。控制面承载的是控制指令，应用怎么部署、流量怎么走、服务异常时怎么处理等。而数据面承载的是业务用户的数据，浏览页面、下载图片、上传视频等。运维系统会对权限、安全、审计等有着比较高的要求，集中管理数据能够很好地满足这一点。而业务存储的是用户数据，为了合规不能跨国家跨地区传输，只能分散就地存储。需要强调的是一般的运维系统并发量不大，能有 10K 台机器的公司就已经颇具规模。如果只是考虑人使用，运维系统能够支撑 1K 的 PV 就足以满足绝大多数公司的需求。运维系统对扩展性的要求比业务系统低很多。
3. CAP 取舍
运维系统选的是 CP，牺牲部分可用性；业务系统选的是 AP，牺牲部分一致性。运维系统对一致性要求更高，宁可接口响应慢一点，也一定要同步地完成各种检测，再返回接口，确认调用成功。否则应该立即回滚，并提示用户。而业务系统会更在乎用户体验，大多数场景下能够直接返回结果，将任务丢到队列中异步处理。
4. 简洁胜过一切
在开发运维系统时，应该基于最少的约束和规则进行设计，再考虑其他细节。运维系统比业务系统复杂很多，运维系统是 ToB 的，而业务系统是 ToC 的。ToC 的产品最终是面向整个人群的，而 ToB 的产品最终是面向垂直领域的，需要阅读文档、反复尝试才能熟练。因此 ToB 通常还会伴随着一个培训市场，对 ToB 的用户进行指导、答疑、提供解决方案等。但运维系统的简洁并不容易，得提升到设计理念的层次，并始终能用这套理念指引系统的设计。这就对团队提出了很高的要求，否则整个产品体系就会显得杂乱无章，用户使用起来也会毫无头绪。想象一下，如果需要进行一次变更，一会儿是命令式，一会儿是声明式，用户使用时得多么迷惑。因此在运维系统设计之初，就要将简洁放在第一位，这是为了抵消因满足业务需求引入的复杂性。对于运维系统，即使采用 ESB 的架构也是足够的，不必强调微服务，更不要谈网格。复杂度的增加是各种问题的根源。
