技术管理可以做什么
2019-01-26 15:00:04 5 举报AI智能生成
登录查看完整内容
技术管理之道
作者其他创作
大纲/内容
技术管理可以做什么
技术视角
稳定性
监控
监控基建
系统监控
页面的200成功率
机器CPU，load，内存
API的系统异常，RT时间
业务监控
业务数据异常下跌（建立基线，同环比）
数据监控
数据一致性校验（分布式系统没办法）
监控覆盖
P1P2的故障点要100%覆盖
衡量指标：故障的监控发现率
报警治理
报警一定要严肃，不然就是狼来了，真正出了问题没人关注
有的系统一天有1000多个报警，形同虚设
系统巡查
模拟客户访问网站页面
可用性
异地多活
备份容灾
性能压测
运维自动化
自动扩容
衡量指标：99.99%
代码质量
建立代码规范
集团代码规范
架构规范
分层机制
分包机制
命名约定
团队约定
编码风格
编码思想
CodeReview
CR要有标准，否则是浪费时间
要重点关注代码的可读性，代码在合入主干以前，要通过专门的Readability Approver的审批
要让团队晒出CR的结果，让写代码的人有所顾忌（类比你checkin代码到github是不是比较谨慎）
how
制定CR流程，指定负责人和KPI挂钩
应用Owner要对代码质量负责
代码通晒
持续学习
why
软件编程是这个世界上，入门门槛最高的行业之一，因此需要时间的打磨和持续学习
学习可以让团队成员有成长
只有不断学习好的编程思想和编程方法，才能做出优雅的设计和整洁的代码
一个有活力的组织，肯定是持续学习的
读书会，同读一本书，互相分享
好的技术书籍 互相推荐
代码好坏味道分享
效率
测试效率
单测覆盖率
日常环境治理
CI可持续集成
自动化接口回归
自动化页面回归
工程效率
代码管理（Git）
开发流程线上化（Aone）
需求管理
bug管理
自动化部署，AB Test
迭代式开发，敏捷开发
整洁代码：代码质量
多端服务收拢（不要无线，m站，网页）都有自己各自的服务
架构治理：统一架构风格和代码风格，不一致性是造成效率底下的重要原因
中台效率
如果有一套系统支撑多个业务方的情况，可以考虑业务身份+扩展点的方式来中台支撑
衡量指标
业务需求的吞吐率（很难量化）
应用复杂度（sona扫描，长方法，重复代码，圈复杂度等）
问卷调查：直接让工程师匿名提交感受
安全
性能
客户体验视角
可以做哪些事
响应时间
前置条件
性能数据打点，可监控，性能数据可视
策略
减少前端响应时间
技术手段有客户端缓存，CDN，文件压缩等
减少后端响应时间
慢SQL调优，系统缓存，水平扩展，异步化等
产品功能体验
收集问题
客户走访，搜集客户反馈
和客满的同学，定期交流，收集客户意见
客户亲听
客户的在线反馈，9点电台，工单平台
组建专门的客户体验优化小组
预留专门的技术资源，对客户问题进行解决 优化
要有专人负责，列入KPI
客户满意度
NPS（可能需要用研介入）
用户咨询数
核心指标提升，比如LD，DO的转化率的提升
业务视角
熟悉业务
客户动线
关键业务节点
业务数据：分析关键业务活动的数据漏斗
数据驱动
业务数据化
是否该沉淀的数据没有沉淀
是否该布置的业务打点没有打
业务数据口径是否有不一致的情况
数据业务化
数据智能
精准匹配
精准推荐
指标：搜索结果L-D的转换率
精准营销
驱动业务发展
数据精细化运营（通过客户动线数据，分析漏斗原因，找到产品和业务机会，然后技术实现）
衡量指标：业务指标（GMV提升，蹦失率降低等）
0 条评论
回复 删除
下一页
