MPD大会笔记

MPD大会

OKR的产品管理

（个人推荐该培训）

OKR

脑力劳动无法考核（以往的考核方式全部失效）；
OKR是一个（更高效）沟通工具，不是管理工具；
OKR的KR，团队内理解，无歧义即可；
google将OKR做到极致，它的全员大会是公开的，可以让员工知道O是从哪来的，并知道它的意义（O需要追问到底，否则和KPI差不多）
结合O，可以反思自己的产品以及公司为什么存在
AI是最符合google的使命感
亚马逊有两个输出：one pizza team 以及 讲个好故事
产品出来后，是否符合我当时讲过的好故事（验证O是否达到与是否偏离）
OKR让大家的行为聚焦公司目标，KPI可能会导致局部利益化
（例如，推送三俗消息，
从KPI角度，日活好，所以KPI好；
从OKR角度，影响了公司的形象，不好）
OKR的常见误区：
1. 团队间不能统一（可以采用见人就讲）；
2. 没有充分沟通；
3. 没有定期回顾；
4. 不看上级OKR；

国内做不好OKR，是因为只是形式上做到了而已。
O不鼓励加数字
KR要符合SMART原则
google不采用OKR进行考核，而是采用同行环评（360评价）
OKR的工具，可以采用innokit

产品经理

产品经理是一个product market meet的角色
需求错了，后面都是白干（很少有反例）
需求，是一个企业值得去解决的问题，只解决用户痛点与需求是一个很初级的产品经理行为
优先级，是产品经理最核心最难的技能
寻找一个形容词（寻找竞争优势，例如，最快的浏览器（想到chrome），最安全的浏览器（想到360浏览器））
形容词，需要日积月累；并能做到让用户主动去找（节省广告）。
没有一个产品能让人记住3个特点，贪心是件很糟糕的事。
用户看十次才有印象，6个月用户才能形成认知。
delighter（超出用户预期）只在一个阶段有用，因为很快会被对手模仿。

TiDB的架构演进和开发测试哲学

架构演进

复杂度是最大的敌人（控制自己膨胀的野心）
选择语言，选择了Rust（不牺牲性能（没有GC，没有run time），并具有安全特性（很多条框限制））——Rust被设计用于取代C和C++
选择数据库，选择了RocksDB
选择开源，选择活跃的
Raft算法复杂度相对低，实现最好（基于CentOS的etcd)
架构设计，分层好，每一层非常隔离，北向、南向有接口，测试用例很好写
TiDB和TiKV分别对应google的F1和spanner。
google领先业界10年，跟随google总是正确的
metric是一个重要环节，可以采用prometheus和grafana（来自google）

测试哲学

测试比开发多一个数量级
分布式有非常多奇怪和复杂的错误，例如时间居然可能往回走
质量来自良好的架构设计和稳健工作（stop talking and go build things)
测试是文化非流程
测试，一开始是强制的
基础软件要用优秀的工程师
基础软件可以做到很高的自动化
业务和测试的时间1:1
profile一切（配置文件化）
为了测试在代码加入辅助测试部分
为了分布式高可靠，测试中引入各种随机错误：
libfiu：Hook Posix API 用户态错误注入（fault injection in userspace）
namazu：干扰调度器注入异常
使用kcov进行测试覆盖率
单元测试覆盖一下，集成测试和开发代码比例是10:1

Docker深入实践

docker：镜像即应用：
1. 运行文件
2. 配置环境
3. 运行环境
4. 运行依赖包
5. 操作系统发行
应用docker化（打包镜像）
docker的日志管理比较特殊，写文件日志在docker无效，可以采用如下方法：
tail -f /var/log/app.log & exec python app...
docker的控制可以通过传递环境变量实现
监控（healthcheck），开发者自己监控，仅传0,1结果给运维。

腾讯DevOps运维

通过他们的TADP平台呈现持续集成的bug
通过coverity检查代码
svn提交代码时，可以加上变量，后端脚本检测到后，分模块编译和进行image构建
运维：标准化，工具化，产品化，服务化
职能化团队：
1. 运营规划
2. 业务运维
3. 有专研精神的，可进行开发式运维；
4. 没有专研精神的，可进行操作性运维；