一个按钮救不了运维：聊聊 SDK、CLI、Portal 三位一体的内部平台设计

作者：Echo_Wish

做运维时间长了，你会发现一个很有意思的现象。

很多公司在搞“内部平台化”的时候，第一反应都是：

做个 Portal。

于是就会出现一个看起来很高级的东西：

DevOps Portal

页面很漂亮，按钮很多：

• 一键部署
• 一键扩容
• 一键回滚
• 一键重启

但半年之后，工程师们的真实行为却是：

ssh + bash

Portal 静静地躺在那里，变成一个“参观系统”。

为什么会这样？

我后来慢慢总结出一个结论：

真正好用的内部平台，一定是 SDK、CLI、Portal 三位一体。

缺一个，都会变形。

今天就跟大家聊聊这个在很多公司被忽视的 平台设计模式。

一、Portal 并不是平台，它只是“界面”

很多公司对内部平台的理解，其实是这样的：

开发人员
   ↓
Portal 页面
   ↓
后端 API
   ↓
K8s / 云资源

结构大概这样：

+-----------+
|  Portal   |
+-----------+
      |
      v
+-----------+
|  API服务  |
+-----------+
      |
      v
+-----------+
|  云平台   |
+-----------+

听起来没毛病，但有一个很致命的问题：

Portal 不适合自动化。

比如你想写一个自动部署脚本：

CI/CD → 调用 Portal？

显然不现实。

Portal 天生是给人点按钮的。

而工程体系真正需要的是：

API
SDK
CLI

所以一个成熟的内部平台，底层应该是：

API First

所有能力都必须先变成 API。

二、SDK：让开发者像用库一样用平台

很多内部平台失败，是因为开发者觉得：

“这平台太麻烦了。”

要申请资源：

开工单
等审批
点 Portal
填表

但如果平台提供 SDK，体验会完全不同。

举个简单例子。

假设我们有一个内部部署平台：

deploy service

如果提供 Python SDK：

# internal_platform_sdk.py

import requests

class DeployClient:

    def __init__(self, token):
        self.token = token
        self.base_url = "https://platform/api"

    def deploy_service(self, name, image, replicas=1):

        payload = {
            "name": name,
            "image": image,
            "replicas": replicas
        }

        r = requests.post(
            f"{self.base_url}/deploy",
            json=payload,
            headers={"Authorization": self.token}
        )

        return r.json()

开发者在 CI 里可以直接用：

from internal_platform_sdk import DeployClient

client = DeployClient(token="xxx")

client.deploy_service(
    name="order-service",
    image="order:v1.3.0",
    replicas=3
)

开发体验立刻变成：

调用函数 = 部署服务

这才是 平台化的真正感觉。

三、CLI：工程师最真实的入口

很多管理者不愿意承认一件事：

工程师更喜欢 CLI。

为什么？

因为 CLI 有三个巨大优势：

可脚本化
速度快
可自动化

所以一个成熟的平台，一定会有 CLI。

比如：

platform deploy order-service

一个简单 CLI 示例：

# platform_cli.py

import click
import requests

API = "https://platform/api"


@click.group()
def cli():
    pass


@cli.command()
@click.argument("service")
@click.argument("image")
def deploy(service, image):

    payload = {
        "service": service,
        "image": image
    }

    r = requests.post(
        f"{API}/deploy",
        json=payload
    )

    print("部署结果:", r.json())


if __name__ == "__main__":
    cli()

使用方式：

platform deploy order-service order:v2

再进一步还能做：

platform logs
platform scale
platform restart

很多成熟平台其实都是这么设计的：

kubectl
aws cli
gcloud

Portal 只是附加层。

四、Portal：最后才是给人看的

Portal 的定位其实应该是：

可视化入口

适合：

• 新手
• 运营人员
• 业务人员
• 查看状态

而不是核心入口。

比如一个部署系统：

Portal 做什么？

查看部署历史
查看服务状态
查看日志
点击触发部署

但真正的部署路径应该是：

CI/CD → SDK / CLI → API

Portal 调用的其实也是同一个 API。

架构就变成：

                +---------+
                | Portal  |
                +----+----+
                     |
                     v
+------+      +------------+      +-------+
| SDK  | ---> | Platform   | ---> | 资源  |
+------+      | API Layer  |      +-------+
              +------------+
                     ^
                     |
                 +---+---+
                 | CLI   |
                 +-------+

这就是：

三位一体架构。

五、三位一体设计的关键原则

我自己在做内部平台的时候，总结过三个原则。

原则一：API First

所有能力必须先有 API。

比如：

创建服务
扩容
部署
回滚

示例：

@app.post("/deploy")
def deploy_service(service: ServiceDeploy):

    k8s.deploy(
        name=service.name,
        image=service.image,
        replicas=service.replicas
    )

    return {"status": "ok"}

然后：

CLI 调用 API
SDK 调用 API
Portal 调用 API

原则二：CLI 是一等公民

很多平台的 CLI 只是“补充工具”。

这是错的。

CLI 应该是：

核心入口

CI/CD 的所有流程都应该能通过 CLI 实现。

例如：

platform deploy
platform rollback
platform scale

这样：

Jenkins
GitLab CI
Argo

都能直接集成。

原则三：Portal 只做可视化

Portal 最大的价值不是操作，而是：

观察

比如：

部署时间线
服务拓扑
资源用量
错误日志

如果 Portal 负责复杂操作，通常会变成：

复杂表单地狱

工程师就不爱用了。

六、我对内部平台的一点真实感受

这些年我见过很多内部平台项目。

失败的有一个共同特点：

太像管理系统。

各种：

审批
流程
表单
权限

最后工程师的真实行为是：

绕过平台
直接 ssh

真正成功的平台反而很简单。

特点只有两个：

好调用
好自动化

工程师甚至感觉不到“平台存在”。

但事情却都自动完成了。

这才是平台工程真正厉害的地方。

结尾

如果让我用一句话总结 SDK + CLI + Portal 设计模式，我会这么说：

平台不是给人点按钮的，而是给系统调用的。

真正的顺序应该是：

API → SDK / CLI → Portal

而不是：

Portal → API