“An application programming interface (API) is a way for two or more computer programs to communicate with each other.”

Wikipedia

概述

提起API，最先呈现在我脑海中的是很多运维人员沉迷于提供贴身式保姆式服务，而不乐于提供API，我想从我的一些真实经历讲一讲其原因及API对运维价值体现的重要性。

还是先说结论：

• 提供API首先得将运维工作软件化

• 运维工作中，除了需要物理操作的部分（搬服务器、插网线、换硬盘等），全部都需要且应该提供自动化API，物理操作也应该提供非自动化API。

• 除因安全考虑不对运维团队外曝光的API外，其余API都应该曝光

• IT行业未来是“软件定义一切，可编程硬件加速一切”的时代

• 运维解决用户的问题，能用产品解决，就不要用服务解决，能用服务解决就不用咨询解决（借用我一位同事的IM签名）

注：

• 本文只说运维相关的领域

• 本人行文风格絮絮叨叨，小学生文笔勿怪

名词解释

产品

一个产品，最起码要有完整的

• 用户控制台和管理后台

• 完善的API、文档和SDK

• 可计量、可计费

• 有售前、中、后服务

• Click或者API调用方式自助化购买、购买后自动化交付

• 现在可能还要加上terraform provider或者什么其他IaC
  

产品的典型代表是：各家公有云可以看作是由数百个子产品组成的超大产品

服务

服务是以人力为重要投入的业务或服务，特点是以人为主体，通过人员的执行来提供价值

服务的典型代表是：运维工单（不管是通过IM、邮件还是通过“工单平台”提的工单）

咨询

咨询则是基于专业知识和技能，通过指导、分析并提供建议等方法来提供的定制化的解决方案或解决客户面临的问题

咨询的典型代表是：AWS SA根据客户需求设计一套适配其业务的网络架构；埃森哲，四大等咨询公司的方案咨询。

产品和服务的区别在于产品是自助化的且自动化的，而服务是非自助化的，可能也是非自动化的；咨询和服务的区别在于服务是“我收到你的需求，我知道怎么做，我帮你做”，而咨询是“我收到你的需求，我知道怎么做，我教你，你自己做”

注：本文所说的API，指的是用户自助调用，功能自动完成的API。虽然工单平台也可以提供API，但是如果其后续操作是人工完成的，就不能称为完全的API化。

运维，为啥你不提供API？

思维

一方面是运维人员自己的思维：很多运维缺乏Computational Thinking（直译为计算思维，但我更偏向于称其为软件思维https://teachyourkidscode.com/what-is-computational-thinking/），运维技术序列门槛比较低（本人也是这种低门槛的受益者），相当多的运维是从某运维细分领域切入之后直接开干，比如Linux、比如网络，比如K8S，而没有受过系统的软件工程教育，导致在后续工作中一直缺少软件思维。工作中遇到实际问题时，通常第一反应可能也是唯一反应就是用自己已有的knowledge和skill去解决眼前问题。当一种思维先入为主之后，后续想打破这种思维，真的需要一些天赋、视野、机遇和能力。

另一方面，是Leader的思维： 一般来说，技术大Boss（CTO/CIO等）主要出身研发，对运维的理解不多，或者对运维的印象还停留在他们做技术的时候，倾向于不花很高的价格去招聘运维，运维就像垃圾桶一样，什么杂活都往运维团队扔，最终客观上也导致运维人才密度相对研发较低，自然也就缺少优秀的软件开发人才。

最后一方面是运维所服务的用户的思维： 主要是研发人员。 一些研发人员也和很多运维一样： “两年经验十年用”，“文档我不读，API我不用，我们研发根本不想去了解运维，我就喜欢用自然语言描述需求，我就喜欢被贴身服务”。这点从研发用公有云也看得出来，很多公司做CMP，可能相当多的研发人员完全没耐心把公有云文档通读一遍也是原因之一，知道VPC，详细了解S3的研发人员比例并不高（个人主观观感）。

能力

主要指编程能力、任务拆解能力，抽象能力等。

很多运维不擅长拆解任务和将工作抽象化以方便后续将其软件化，他们甚至自己也说不清自己到底做了哪些事情，一年到头来写年终总结时，既记不起来完成了什么大型项目，也说不出来提升了哪些深层次能力。 这就跟以前工厂里面操作机器的工人没有太大区别，在工厂里面，只有极少量工人能够发明新工具或改进机器、制造工艺。

从本质上来说，运维工作中除了直接需要人力物理操作的部分，其余的也是跟软件打交道（对硬件的配置、调优也是通过软件工具进行的），虽然这些软件可能相对业务程序会更底层一些，但是这些软件实际上已经被云厂商证明了是可以拆解和抽象，经过编程和封装最终输出成为一个个产品的。

运维打交道的对象一般是： 硬件（Infra、IDC、服务器、网络设备），操作系统（主要为Linux、配置、内核参数，硬件参数），Runtime，中间件，各类开源软件和一些Framework，保证其正常稳定run起来就完事。 过去十几年，运维从业者主要通过手工CLI或写脚本进行操作，也习惯了这样的操作，相较于自己不熟悉的软件开发，他们天然会更信任硬件和自己的手工经验。 而且很多过去的老硬件，或者历史遗留系统，它们也没有API，运维自然就更无法提供API了。

不过这个现象随着硬件厂商的没落，开源软件的崛起，Devops，云原生的流行，已经在慢慢改善了，可以看到有一些运维已经具备了开发能力和提供API的能力，但是可能还不规范、不标准、覆盖面不够广、程度不够深。

考核机制

如果公司对运维的考核依然是：服务稳定性、工单数量、故障数量、成本压缩，那么运维自然不会将主要精力放在API提供上，毕竟运维普遍因为上面所说的能力和思维问题，更信任自己的经验，而不是自己写的软件。

另外，如果从局部来看，将其软件化的ROI是负的，那想要运维积极主动做这个事，可能性就比较小。比如安装配置启动一个开源软件报错了，运维可以根据CLI界面的输出去判断到底是啥原因，从而解决它，而将此操作代码化时，必然无法将所有报错场景都考虑完全，毕竟很多报错可能自己也是第一次见，而手动操作时，自己见到之后，直接谷歌解决它就完事了，可能也就两分钟，而将其软件化会花费更多的时间。

所以需要自上而下的推动，例如假设公司把对运维的考核指标定为：提高API提供率和API曝光率，那我相信运维也会开始卷API，即使是后面就是个Python调Shell，也会提供出来。

领地意识

有一些运维，喜欢刻意或非刻意地将自己的工作神秘化、模糊化、笼统化、黑盒化，将别人介入自己工作的后果严重化，从而获得“职场寻租”空间，让自己成为这块工作在公司内的权威，让自己的地位更稳固，提高不可替代性。

原理同 《如何写出让同事无法维护的代码》 ，当然，这个是夸张写法，但是在我的工作经历中，确实见过不少领地意识很强的人，喜欢先保住自己的基本盘，然后去抢别人的活，自己是这样，自然就也这样看别人： 担心自己提供API之后，被别的团队封装出很薄的一层，再加一些你没提供的功能就向上抢功，这种常见于“从0到1做新平台得高绩效”的公司。 关于这点，其实大家更熟知的应该是ToC产品，比如游戏，比如微信，其不太可能提供API给外界，只要有API了，分分钟辅助、外挂、微信Plus就出来了。 内部平台一个道理。

我记得我大二时，去北科附近一家软件公司实习，有次我帮我隔壁的一位销售重装了一下她笔记本电脑（公司资产）的操作系统，就被公司的IT人员怒批了一顿，大致意思是你凭什么越俎代庖，要是你把公司资产弄坏了，你负得起责任吗？

还有某云想让其兄弟部门提供一个API，大头兵直接说：“这我可不敢擅自提供，你去问一下X哥（总监、GM等），他们拍板了我立马提供”，而这些X哥在团队内说的就是：你提供API，后面出了问题就你负责，另外后面要是没活了就优先裁你。

这个现象在个人、团队、部门、BU、公司乃至行业、国家之间都普遍存在，每个个体和组织都在这个大争之世有强烈的不安全感，因而希望掌控一切，减少不确定性。大家拼了命的想要制造护城河，都有一颗想要垄断的心，差别无非是垄断的地盘大小而已，互相抢对方的地盘都嫌不够，我还跟你合作，提供API给你？

意愿

说白了就是懒。能够持续思考，持续学习，持续更新是一种能力。躺在舒适区，一年经验重复十年当然是安逸滴很，反之则会有不短的一段痛苦期，这点懂得都懂就不多说了，个人选择而已，未来假如被时代淘汰时别后悔就行。

不提供API的运维，不是好运维

提供API是不可避免的

虽然很多运维部门不提供API（机机交互），但是会提供一个带有前端的运维平台（人机交互），说实话，这种也没办法避免别人再去套一层。如果某个功能的API是用户的强需求时，用户会直接抓前端API调用，毕竟内部平台一般不会花大力气去做反爬虫，而且大概率是用同一套权限系统，做起来相对简单。

两个案例：

案例一：有个团队B在团队A提供的平台A1页面抓了前端API，直接包装到自己的平台B1中开始调用（因为内部通用一套权限和认证系统，拿到一个TOKEN，可以直接调用部门内所有系统前端和后端API，而且第一版时，TOKEN还没有过期机制，后来第二版时花了好大功夫治理）

后来A团队对平台A1做变更时，API升版本了，本来已经变更成功，最后B部门找来了，说你怎么变更API不通知下游，好了，现在出故障了，你得写个FMS😂

案例二：《 判赔6140余万，全能车不正当竞争案落槌 》，类似的案例其实还有，比如有人把各家视频平台聚合成一个视频平台，各家音乐APP聚合成一个（虽然这个确实方便了用户使用哈，但是这个确实是违法的）

可以看出如果仅是为了保护地盘，只提供人机交互界面而把API藏着掖着没太大意义，想不正当利用你平台的人总能找到方法，藏是藏不住的。

其次运维提供的是计算，网络，存储等infra，OS，runtime，MiddleWare等，无论被什么人经过怎样的封装，最终这些实体都是运维提供的，且上级也知道是你提供的，假设CTO/CIO在一个业务部门的某平台上看到可以创建一台虚拟机，他不会认为这是业务部门自己提供的VM吧？

最后，运维对内提供服务，也没啥包年包月，折扣，优惠的必要，反正全部是按量付费，入口是哪里不重要。

所以，既然躲不掉，那还不如就大大方方的提供API，方便你的用户，至于对不正当使用你API的人或组织，通过法律法规和组织内规定、流程、评价制度等去制约。

API提供了无限的可能性

有了API之后就有了无限的可能性，按笔者经验来说，你提供了API之后，会有各种各样你意想不到的用法，你的用户也会封装你的API去做各种各样贴合其业务的平台和系统，有些奇奇怪怪的用法、骚操作你知道之后可能会惊掉下巴。

许多人谈及SDN时会最先想到：控制面转发面分离，统一的集中式管控；提及NFV时想到的就是网络功能虚拟化。但实际上这些是手段，而不是最终目的，最终目的是为了软件定义一切，当一个东西被软件定义之后，才会有丰富的可能性。

很多云厂商早期都提供过一种叫做“经典网络”（对应“VPC网络”）的产品，需要注意的是，如果从SDN的定义来看，其不能被称为SDN，因为其仍然采用传统网络那一套实现的，这种经典网络用到的设备和技术，与一个普通的CCIE在IDC中用CLI操作的设备和技术没有任何区别，转发和控制仍然没有分离，但是我仍愿意称之为SDN，因为其将网络运维的配置工作软件化了。正是这个将“网络运维工作软件化”的尝试，提供出网络的API，才成就了早期版本的公有云，不然光有虚拟化，没有SDN，那云计算也是玩不转的。

当时硬件网络设备的API、GRPC、NETCONF都非常不完善甚至压根没有，云厂商SDN工程师就是采用简单粗暴的模拟Telnet/SSH登录到设备执行CLI命令去实现SDN的。

后来，虽然硬件厂商不断地迭代自己的盒子，加上各种所谓的SDN/云网络/Overlay功能，比如VXLAN-EVPN，Trill，完善API，NETCONF，Yang-model等，但是效率依然赶不上云计算的需求，最后的结果大家也看到了： 硬件Overlay被彻底抛弃，现在云厂商基本都采用软件Overlay： 用服务器NFV实现各种网络功能。 API问题，即功能问题解决之后，再回过头来捣鼓性能问题，DPDK/VPP over 25G/100G服务器，SmartNic、DPU、P4等都慢慢出现了。 当然，在这个过程中，作为一个背景板，手工达人CCIE/HCIE迅速贬值了。