分享我的技术调研流程

佳境Shmily 2020-01-03 21:10:00
技术

技术调研流程分享

为何制定流程?
明确调研需求,提高调研文档质量,规范调研流程,保证调研产出。

我是如何制定调研流程的?
先总结一版自己的调研流程,再查阅资料以及查看阿里等大厂的调研报告,结合部门目前的实际情况来明确部门的调研流程。

技术调研流程

整个调研流程分四个阶段

第一阶段:需求分析

  1. 分析目前/未来可能出现的瓶颈点
  2. 明确调研目标和方向(为了实现新需求?为了优化瓶颈点?)
  3. 引入新工具后的结果衡量(效率提升、成本降低等,如何衡量)
  4. 结构化思考新工具引入的目标和衡量标准:场景(适用场景、知识要求)、效率(性能、效果预测)、成本(容量、硬件资源、维护成本)、稳定性(故障分析工具、监控完善度)等

第二阶段:准备阶段

  1. 理解需求
  2. 结合现状评估可行性和收益

第三阶段:调研阶段

  1. 简单调研
    • 短时间内粗略了解所调研技术的应用场景和部署环境,进一步评估和权衡可行性和收益
    • 经过权衡后发现值得调研,发送邮件至直接上级并抄送部门Leader (标题:申请调研xxx 内容:简述xxx值得详细调研的理由)
    • 协商决定是否批准,若批准,则开始进入详细调研阶段
  2. 详细调研
    包括但不限于:
    • 先设计调研方法与调研过程
    • 预估调研时间,并在北森设定Deadline,根据调研报告的要求按时完成调研报告
    • 了解相关技术在其他公司的应用及收益
    • 原理及核心技术调研
    • 总结适合我们的场景及解决方案
    • 调研过程遇到的问题与解决方案
    • 未解决的问题/收集需求可随时讨论,有必要的话可以开讨论会
    • 设计落地方案

第四阶段:反馈与落地

  1. 调研反馈
    • 必须产出一份调研报告
    • 选择反馈形式:分享会、文档、邮件、群通知(如果是分享会,则要有完善的PPT,会前共享出来)
  2. 技术落地
    • 根据自己设计的落地方案得出详细的部署文档和使用文档
    • 配合运维部署

后续阶段:落地后如何跟进

  1. 出现问题及时跟进解决,并把问题与解决方案更新到使用文档中,如果影响较大,要在更新完使用文档后发群通知。
  2. 相关的新人文档/Wiki更新

文档要求

所有调研文档统一保存在gitlab部门文档中的技术调研文档目录

  1. 部署文档要求
    这部分为了方便让运维人员傻瓜式部署,并可以把简单的运维工作交给运维。
    • 尽量打包好主从节点的分发包(提前编译好) 例:
      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
      ...
    • 尽量写出部署过程可能的报错及解决方案
    • 常用维护方案总结
  2. 使用文档要求
    这部分目的是方便大家使用新技术新组件。
    • 格式包括不限于
      场景1:示例代码/操作
      场景2:示例代码/操作
      场景3:示例代码/操作
      ...
    • 常见错误及解决
    • 遇到问题请联系:调研人
  3. 调研报告要求
    这部分的目的是调研时可能有遗漏的点,可以从这个列表里做参考。
    开头写清 标题 + 调研人 + 调研时间
    可以参考不限于这些点:
    • xx是什么
    • xx的优缺点
    • xx的应用场景
    • xx的功能/特性
    • xx的原理与架构简述
    • 相似技术横向对比
    • 初步评估带来的收益
    • 遇到的问题Q&A
    • xx的兼容性(支持什么不支持什么)
    • xx技术的核心点
    • xx的性能与扩展性(测试结果)
    • xx的部署难度
    • 如何部署与简单实践
    • 应用该技术带来的工作量和学习成本
    • 总结

注意事项

  1. 关注缺点的优先级高于关注优点的优先级(优点再多,也可能因为一个缺点而不能被应用)
  2. 明确场景,及时沟通需求,明确需求细节
  3. 多搜集信息,不急于出结果(搜集足够的信息才能做出比较准确的判断)
  4. 要从可行性,稳定性,可维护性,工作量和学习成本等几个重要方面考虑
  5. 合理安排时间,自己规定了Deadline,就要及时交付反馈