一个工程师的目标修养

目标是什么

人嘛，总是喜欢找理由，比如我们做什么事情的时候，就需要说服自己和别人，我们的目标是什么，我们为什么这么做，有几种办法做，为什么这种是最优的。

当然，我们在公司做工程师也一样，开发一个新系统、新模块，修改一个老流程、老问题，迁移一个老业务、老系统，也都会问自己，目标是什么，最优的方法是什么。

但是，在产品、运营和我们讲的时候，产品会说用户体验，运营会说用户规模，那么如果两个的方案不同甚至冲突的时候，哪个才是准绳呢？

大学老师在讲公司管理课的时候告诉我们公司是以营利为目的的组织，那么组织的最大目的就是最大规模的盈利。

哪些会对一个业务的盈利造成影响，就是我们对目标的衡量标准。

影响利润的因素

一个经典的公式：利润=收入-成本

哪些会对利润产生影响，业务内容是最重要的一部分，如果一个新的业务产生，想象空间巨大，那么对当前的目标有促进和强化作用，那么是可取的。

另外如果是一个老的业务，从内因看，规模、效率、质量、成本上是影响利润的直接因素；从外因看，政策、经济、技术、文化等影响大，暂不深入。

扩大规模后，单个产品利润短期不变，边际成本降低，所以是增加了利润收入；提升当前生产效率是降低单位产品成本，所以增加了利润收入；质量和品牌影响力提升增加用户使用和购买意愿，所以是影响需求端的重要因素，影响利润规模；成本当然依赖前几项，当然也有针对成本的单独优化，使当前规模和利润不变的情况下，增加利润，一般出现在产品的中后期。

作为工程师，工程师的价值可以对利润产生直接或间接影响，例如互联网系统的稳定性（例如用户系统的稳定性，有问题很要命），例如网页的响应时间对用户产生直接影响。

系统对规模的支撑

系统对业务规模的支撑分为几个类型，从数据的结构上看，分为结构化数据和非结构化数据，从使用的场景上分为增删改查。

结构化数据存储

结构化数据当前的常用方案为mysql、mongodb、mysql server、redis、mola，以上为非时间序列；influxdb、rrdtool等时间序列的数据库。

百万级别的数据，使用常见的存储结构满足业务需求（单库、单表、单机或多机容灾、单机房或多机房）。

千万到百亿级别的数据，使用分治法处理（分库、分表、多机器、多集群、多机房）。

百亿以上级别的数据，使用多中类型系统及基础设施结合治理。

非结构化数据存储

常见的图片、视频、音频、软件包等，都为文件数据，大小不一，meta数据提取后需要使用非结构化的文件存储系统处理。

当前使用nfs、afs等分布式系统，文件使用根据规模和效率使用不同的机器，sata盘还是ssd（一般考虑使用成本，分级存储，热数据使用ssd，冷数据使用sata）。

语言对规模的支撑

c语言无疑是当前执行效率最高的语言，通常将较成熟的算法封装使用。

考虑开发迭代、维护等成本，快速迭代业务会使用java、php、python、go语言，例如接口相关、界面相关、业务流程及逻辑相关。

系统对效率的支撑

业务系统对业务的支撑从无到有，从有到优，从优到细。

例如地推这个业务，传统模式是手记录，每天小组长汇总，之后进行整体汇总，这个过程漫长、易错，那么系统提升的第一步是信息化，地推人员信息、拉新用户、消费客单价等，这些信息化后，一方面提升推广效率，另一方面可以大规模的协同和短时间的反馈，例如之前一周一个活动，现在每天可以做活动，每天出效果和排行数据，从线下交互升级为线上交互。

信息化仅仅是业务跑通的第一步，期间还有很多的流程会有往复和非系统交互，例如邮件，第二步是流程化，使用批处理或其他手段，打通多个系统和业务，形成半自动的系统流程，人做审核和干预，例如支付和第三方对账，数据打通后可以使用机器对账，流程可以从月级别优化到天甚至小时级别，从大部分人链接系统升级为系统链接职能的人（审批、审核等）。

第三步是实时流，就像标准生产的流水线一样，一个不多，一个不少，灵活定制，让流程和效率达到最优，在处理速度和衔接环节上做到实时通知、实时处理。

系统对质量的支撑

互联网提供的产品就系统本身的功能，系统的sla最核心的是安全性、稳定性、问题响应时间，下一个十年是公司固化的十年，因为版权法会对数据的流动产生封禁作用，核心用户数据无法低成本流通后，新的巨无霸产品崛起的成本就会增加，这和当前互联网的拉新成本越来越高互为印证，数据安全将是未来产品的基本要求。

对质量的把控，大的产品都有QA团队，做发布前的业务检查、类似产品线的品控一样，对接口功能、性能、安全、维护性、扩展性等做检查，做到事前保障。

稳定性通过常见的监控系统承载、展示，类似google的dapper系统，可以查看每一次业务请求的依赖，每个请求都是一个有向无环图，通过图可以看出调用路径、深度、耗时、错误等关键信息，进而对产品质量的事后发现、定位提供快速解决的手段。

传统产品需要召回返修，互联网产品需要修复、升级、发布（app产品，仅是后端升级即可），在这个修复的过程中，大产品需要涉及问题定位、职责定位、问题规模、修复方案、修复跟进人及后续修复效果评估。

系统对成本的优化

通过复用降低边际成本。

存储复用

业务在发展迭代的过程中，会出现多个业务系统、多个存储系统、多个业务部门，在业务交叉或空白的地方总会存在多个存储系统，做无关紧要的事，因为老系统排期或者资源协调，搭建新的数服务，在整体看，多个数据中心增加了数据协商一致的成本，也增加业务部门间的交互和人力成本。故存储的设计需要最早考虑，业务最影响后续业务迭代的基础服务，如果存储层面升级，基于系统搭建的各个业务系统及使用流程大概率需要升级或迁移。

服务复用

常见的系统配置、权限管理、用户信息，基本每个子系统都会涉及，所以初期的时候涉及并服务化，对后续的升级迭代提升效果明显，自然的迭代流程往往导致没有统一的权限管理、配置管理和用户中心。

流程复用

大部分的产品分为数据生成端，我称为P，数据消费端，我成为C，也就是PC结构，生产者和消费者，往往也有两个部门（通俗的叫B端和C端，2B类业务），两拨人、两个老大、两条流程，那么很多功能的子流程可以复用，例如相似判断、去重、标签挖掘、检索、安全检查、基础业务库等。现实是几波人几个库，几个流程，那么中间的数据流转就不是生产线的直线，是曲折的交互，在业务数据的处理效率和质量提升上产生不好的影响，所以初期应该规定某些系统的唯一性和负责人。