技术调研流程分享
为何制定流程?
明确调研需求,提高调研文档质量,规范调研流程,保证调研产出。
我是如何制定调研流程的?
先总结一版自己的调研流程,再查阅资料以及查看阿里等大厂的调研报告,结合部门目前的实际情况来明确部门的调研流程。
技术调研流程
整个调研流程分四个阶段
第一阶段:需求分析
- 分析目前/未来可能出现的瓶颈点
- 明确调研目标和方向(为了实现新需求?为了优化瓶颈点?)
- 引入新工具后的结果衡量(效率提升、成本降低等,如何衡量)
- 结构化思考新工具引入的目标和衡量标准:场景(适用场景、知识要求)、效率(性能、效果预测)、成本(容量、硬件资源、维护成本)、稳定性(故障分析工具、监控完善度)等
第二阶段:准备阶段
- 理解需求
- 结合现状评估可行性和收益
第三阶段:调研阶段
- 简单调研
- 短时间内粗略了解所调研技术的应用场景和部署环境,进一步评估和权衡可行性和收益
- 经过权衡后发现值得调研,发送邮件至直接上级并抄送部门Leader (标题:申请调研xxx 内容:简述xxx值得详细调研的理由)
- 协商决定是否批准,若批准,则开始进入详细调研阶段
- 详细调研
包括但不限于:- 先设计调研方法与调研过程
- 预估调研时间,并在北森设定Deadline,根据调研报告的要求按时完成调研报告
- 了解相关技术在其他公司的应用及收益
- 原理及核心技术调研
- 总结适合我们的场景及解决方案
- 调研过程遇到的问题与解决方案
- 未解决的问题/收集需求可随时讨论,有必要的话可以开讨论会
- 设计落地方案
第四阶段:反馈与落地
- 调研反馈
- 必须产出一份调研报告
- 选择反馈形式:分享会、文档、邮件、群通知(如果是分享会,则要有完善的PPT,会前共享出来)
- 技术落地
- 根据自己设计的落地方案得出详细的部署文档和使用文档
- 配合运维部署
后续阶段:落地后如何跟进
- 出现问题及时跟进解决,并把问题与解决方案更新到使用文档中,如果影响较大,要在更新完使用文档后发群通知。
- 相关的新人文档/Wiki更新
文档要求
所有调研文档统一保存在gitlab部门文档中的技术调研文档目录
- 部署文档要求
这部分为了方便让运维人员傻瓜式部署,并可以把简单的运维工作交给运维。- 尽量打包好主从节点的分发包(提前编译好) 例:
xxx-master.zip xxx-worker.zip 或整理conf配置文件包 xxx-master-conf.zip xxx-worker-conf.zip - 尽量采用傻瓜式命令 例:
sudo -uhdfs tar -zxvf /opt/alluxio-2.1.0-bin.tar.gz -C /opt/ sudo -uhdfs sh /opt/alluxio-2.1.0/bin/alluxio-start.sh master sudo -uhdfs sh /opt/alluxio-2.1.0/bin/alluxio-start.sh worker chmod 777 /opt/alluxio-2.1.0/logs/user ...
- 尽量写出部署过程可能的报错及解决方案
- 常用维护方案总结
- 尽量打包好主从节点的分发包(提前编译好) 例:
- 使用文档要求
这部分目的是方便大家使用新技术新组件。- 格式包括但不限于:
场景1:示例代码/操作 场景2:示例代码/操作 场景3:示例代码/操作 ...
- 常见错误及解决
- 遇到问题请联系:调研人
- 格式包括但不限于:
- 调研报告要求
这部分的目的是调研时可能有遗漏的点,可以从这个列表里做参考。
开头写清 标题 + 调研人 + 调研时间
可以参考但不限于这些点:- xx是什么
- xx的优缺点
- xx的应用场景
- xx的功能/特性
- xx的原理与架构简述
- 相似技术横向对比
- 初步评估带来的收益
- 遇到的问题Q&A
- xx的兼容性(支持什么不支持什么)
- xx技术的核心点
- xx的性能与扩展性(测试结果)
- xx的部署难度
- 如何部署与简单实践
- 应用该技术带来的工作量和学习成本
- 总结
注意事项
- 关注缺点的优先级高于关注优点的优先级(优点再多,也可能因为一个缺点而不能被应用)
- 明确场景,及时沟通需求,明确需求细节
- 多搜集信息,不急于出结果(搜集足够的信息才能做出比较准确的判断)
- 要从可行性,稳定性,可维护性,工作量和学习成本等几个重要方面考虑
- 合理安排时间,自己规定了Deadline,就要及时交付反馈