我的技术产品观

前言

恍然间，入职涂鸦X团队即将满半年了，深圳的X小团队也是我来后才真正成立的。在杭州外的其他地方成立新团队，DL表现了莫大的勇气和决心，背后是对我的直接的无条件的信任，在此我由衷的表示感谢！

在过去的半年里，我不急不躁的了解着团队的现状及做事风格，期望自己能够平滑的过度，对在涂鸦的未来，我保持着信心！

我为什么来涂鸦呢？答案是“超越大头兵”，这是最初的想法，我不确定我当前是否做到了，我还在探索如何才算超越了大头兵，但是在这个问题上我对自己很宽容，我给自己时间，不急切，我相信自己。

我对自己的定位

在前一家公司听过一个技术大佬的分享，有一段印象深刻的讲述，大意是我们每个人要定义好自己的“点线面体”，朝着解决更高维度的问题的能力自我迭代。我当前对自己的定位就是从这里出发的——解决一个“面”的问题，并能在帮助团队解决“体”的问题上做出贡献。

入职前后，我曾问过DL我可以帮助X团队解决什么问题？当时接收到的信息是团队当前系统较为零散，有待提升体系化。显然这个问题不好解决，可以套一套上面这个理论，结论是我期望在帮助团队解决体系化的问题上做出贡献。后面我想，当前阶段体系化其实可以约等于产品化，那么这个抓手就有了，目标可以是帮助微服务方向系统产品化。另外，关于“面”是什么问题呢？就是做好一个或多个技术产品。在DL及L对我提出新的要求前，根据自己过往的习惯和经验，我对自己的要求是每年都要做好一款产品。

体系化这个词其实理解起来是模糊的，直接感受是好像有好多东西，但是好像又什么都拿不出手。 根据我入职半年来的观察和感受，初步有了一定理解，下面我尝试通过几个小问题，拆解并定义这个大问题：

1. 鲜有人谈论做产品，团队内习惯于做技术方案，做架构，而不是做技术产品。
2. 团队内部不追求用户体验。
3. 较少准确定义技术价值，没有沉淀出来及验证技术方法论，产品化无从下手。
4. 认为产品经理无价值，也没有去培养团队的产品意识。

总结一下，其实就是团队不重视产品这个维度的概念。

我的产品观

我罗列了以下几个产品，尝试帮助微服务方向实现产品化的目标。如果我们真正稳稳的走好产品路，我相信一年后能开始初见成效，两年后微服务方向可以实现拿得出手，走得出去，讲得出来，团队成员综合能力借此能得到较好提升。这几个独立产品分别是：

1. 统一服务治理中心
2. 服务稳定性平台
3. 微服务平台
4. 框架与工具平台
5. 配置中心
6. 微服务API网关
7. 服务网格

统一服务治理中心

我认为服务治理是微服务方向最重要也是最为核心的系统，放到整个大团队来说，也是处于核心的位置。系统定位服务于rpc请求的动态流量治理、可视化、自动化运维等能力，可规划具备以下功能：

1. 多维度的服务可视化（应用、服务提供者、服务消费者、实例）
2. 微服务概览（多区域应用部署详情、版本等概要及统计信息）
3. dubbo元数据管理（包含4个维度的数据查询、治理规则数据查询等，以OpenAPI形式开放给外部系统使用）
4. 接口文档管理
5. 服务链路（接口的上下游依赖信息、强弱依赖标注等功能）
6. 路由（条件路由及标签路由）
7. 限流（针对dubbo接口的常用的限流快捷通道）
8. 服务上下线（无损发布、实例启用与禁用）
9. 接口鉴权
10. 接口实时测试（主要是dubbo接口的调测，也可以囊括http接口）
11. 弹性能力（请求过滤、接口降级、巡检、重试策略等）
12. 全链路灰度（行业当前非常火的概念）
13. 流量录制
14. dubbo管控台的动态配置（动态负载均衡、权重等）
15. 用户视角的工作台
16. 跨语言治理融合（比如go技术栈）
17. servicemesh治理融合（servicemesh是新概念不是新技术，其治理方式没有完全新的技术）
18. zk节点可视化
19. 注册中心运维自动化等管理与监控功能（注册中心是非常核心的组件，我们应该朝着杜绝黑屏操作的方向努力）

当前服务治理主要由dubbo管控台承担，其基于dubbo框架提供了常用基础的功能。但是由于功能特性较为基础，也不丰富，难以承载服务治理核心系统的定位及使命。建议要尽早走向自研，以做产品的思路，理解行业内服务治理的各个名词，实现为我们的系统能力，并不断增加能力要素，构建技术壁垒。后续积极运营，培养用户使用习惯，赋能业务。

稳定性服务平台

即当前的预案中心，希望对标阿里云的应用高可用服务AHAS，逐步建设开关预案、通用预案、限流熔断、故障演练等能力，并延伸边界尝试与故障管理、混沌工程等系统打通，在业务稳定性方面持续挖掘可以在更多场景下应用的能力。如果按此规划迭代，后续可以考虑改名为“稳定性服务平台”。以下我简单介绍下规划的能力：
1）开关预案（已完成设计）
将程序中的开关等配置，抽取到开关预案页面统一管理维护，具备开关定义、开关上报、开关下发、下发规则、审计与权限等能力。
2）通用预案（已交付）
关注预案的通用能力及扩展性，期望后期融入监控体系，并可关联故障管理系统，在故障自愈、预案演练等流程中承担一定职责。
3）限流熔断（测试中）
融合sentinel作为限流承载系统，实现资源的抽象定义、规则的统一管理及下发等标准限流功能，后续将尝试打通sevicemesh中的限流功能。
4）故障演练（规划中）
借助混沌工程基础能力，打通故障管理系统，抽象各种故障场景形成场景化的方案，打造故障演练管理功能，帮助业务系统提升稳定性，并可赋能sevicemesh系统，丰富其故障注入能力。

微服务平台

B同学已经在落地这个系统，走出了产品化的重要一步。上次评审时我也表达了我的观点：做流程串联。

框架与工具平台

有句话叫“做产品，不要做工具”，然而工具是必不可少的，我的理解是将工具服务化、平台化，尽量不要提供裸的工具出去，当前存在的一些没有界面的框架或者工具，可以朝着平台化、可视化的方向去产品化迭代。当然，这是理想化的，但是至少我们有了方向，而且我们往往缺乏的不是技术，是方向，我们需要帮助这些工具的owner提供方向或者思路。

微服务API网关

API网关在微服务业务架构治理上，是重要的工具，有时会被纳入服务治理体系，一般作为独立的产品呈现。作为微服务rpc入口网关，它能帮助业务单元化，实现单元内与外界隔离。主要能力为请求路由、协议转换、权限控制、对外接口管理、流量治理等。

服务网格

servicemesh能将流量治理从业务代码中抽离出来，一定程度摆脱了SDK接入、升级的痛苦，让业务方只关注于业务研发，业务流程更加敏捷。随着云原生概念被大家接受并逐步普及，以及开源的跟进，servicemesh架构升级将势在必行。

如何落地

如果问题已经明确了，解决问题的方向明朗的话，接下来就是如何落地的问题了。俗话说解决问题的方法总比问题要多，这里我认为首先要转变思维，从做技术方案转变为做技术产品，我的思路如下：

1）具象化工作价值。
我们常谈价值，但是我们是否搞清楚了每件认为有价值的事情的价值，有待自问自答。我理解的价值可大致分为三类，分别是业务价值、技术价值、产品价值，我们常谈的价值更多指的是业务价值。这个其实是业务驱动的，当帮助业务方解决了某个层面的问题后，我们就体现了我们的价值。我们习惯于追求好的技术解决方案，喜欢做架构，这其实追求的是技术价值。我们在通过技术方案解决业务问题时，常为做出了合理的技术方案而欣喜，却往往忽略产品价值。其实我们的项目管理系统lean已经为我们分好类了——需求分为业务、产品、技术三个类别，中间件系统同样适用。

2）做产品不要急功近利。
当摸着石头过河时，我们不能指望快速做出一个好的产品，这个情况我们首先需要多思考，常规划，规划长远——看到产品更远的未来。往往需要我们在这个产品上投入足够多的时间和精力后，才能迭代出一个好的产品。当然如果我们对这个产品的认知足够清晰深入，在人手足够时也可以快速做出来，显然当前微服务团队还处在摸索产品形态这样一个阶段。

3）掌握适当的产品思维。
一个好的产品是没办法一蹴而就的，迭代思维是产品思维的核心要素。我们需要与业务团队保持紧密的沟通，深入业务团队内部理解其面临的问题，进行一定的抽象，不急不躁，以产品能力的方式来帮助解决问题，通过迭代产品的方式来完善产品体系覆盖面。据我观察，我们是缺乏与业务团队长效的沟通机制的，不能指望每个研发都有很强的人际沟通能力，我们需要将这种沟通机制制度化。当我们不能准确定义我们的产品方向时，不妨换一种思路——做“行业名词”。比如“全链路灰度”能够帮助我们解决研发同学常吐槽的必须去预发才能跑通逻辑的问题吗？

4）注重用户体验。
用户体验直接决定了用户评价一个产品的好与坏，直接决定了中间件团队的技术影响力。如果要走得出去，还需要口碑。

5）引入适当的UI/UE设计。
当产品迭代到一定阶段后，通过引入UE设计，能在改善系统的整体交互体验及页面布局方便带来一定效果，让用户不仅用起来爽，还不能看起来感受起来觉得low。

6）给核心人员定产品化的KPI。
想让大家走出做技术方案的舒适区，还是得有这个压力，KPI工具是很好用的。

深圳团队的现状

系统现状

当前深圳团队有三个人，精力分散在三个系统：预案中心、认证鉴权中心、sigmax。预案中心我的想法是规划成“稳定性服务平台”，上面已经提到了。至于认证鉴权中心，当前的定位是服务于系统间的权限控制，我建议后续与大团队内部的ACL系统融合，规划成一个大的权限控制平台这样的产品，否则由于其产品能力较为局限，很难说能做成一个能独立拿得出手的产品。至于sigmax，数据量很大，稳定性保障堪忧。另外在数据安全性上问题突出，我们目前不能保证如果出现较大事故，能全量恢复数据，或者说没有从零恢复的能力。目前也未对数据分级，不明确哪些数据如果丢失了会对业务造成怎么样的损失。要做到这一点，我们需要首先进行一些精细化运维开发，进行数据分析，做到对数据现状了然于胸。

团队协作

深圳小团队其他人都是go技术栈，而我是java栈，我仅能在规划及技术方案上对他们有所帮助。无论是java的一个人还是go的两个人，是不具备做好一款大的产品的条件的。鉴于他们不懂java，转到庞杂的java体系是很难的，反而我转向go是具备行业及现实条件的，问题在于我们使用go语言做什么？

我的期望

在不违背团队整体规划的前提下，做产品而不做工具是我个人的追求，那么我做什么比较合适呢？深圳团队做什么比较合适呢？我个人也需要成长，因此答案也是明确的，那就是服务网格或者服务稳定性平台。服务网格项目在帮助深圳团队整体转向go有很好的资源条件，每次跟M和N聊下个季度我们做什么时，他们就提到能不能搞servicemesh。在我看来，除了天然的资源条件外，深圳团队落地这个也没有前置负担，对产品化有利，能避免只是在做技术。至于规划的稳定性服务平台，如果不能由深圳团队落地servicemesh，那么DL能否尝试协调下，把混沌工程要过来呢？或者站在DL和L的角度，对我或者深圳团队有另外的定位或者想法，我也期待。

关于跨地域团队协作

行业建立跨地域的团队，一般是将独立的一块业务交给这个团队。至于目前X团队内部跨地域协作，我认为基本是不存在大问题的，因为与L时常保持着很及时和直接的沟通，频次也不少。也有可优化的点，比如我多次提到期望将线下沟通固定化，例如在每个季度深圳或者杭州团队，能去对方的城市沟通交流，交流内容可以固定化，比如技术运营、与业务团队交流、团建等可选。另外在会议上如果能有些仪式感就更好了，比如能相互看到大家的脸，说话大家都能听得到。当然这个还需要我们的会议室系统支持。总之跨地域的团队协作，核心还是要保持密切的沟通。

最后

我真实的期望我能帮助X团队解决一些实际的问题，产出较好价值。但是我们也知道，靠少数一两个人的能力是远远不够的，需要靠整个团队齐心协力，尤其是解决一些难的问题，需要团队里的所有人都成长，心往一处想，力往一处使。我对我们团队的未来充满信息，对涂鸦的未来充满信心。