怎么写好一个技术方案

怎么写好一个技术方案

本文作为运维或开发面临转型,或者其他种种原因需要写技术方案时的一个初级版分解。


三大忌讳

切勿不清楚方案目的就开始写方案
切勿一上来就直接写技术内容
切勿思路不清晰就开始写方案

正文内容

这里拿日志方案作为案例

目的:
日志方案能够提供什么样的能力?
—切勿一上来就直接写技术内容–

业务层面:

  1. 有哪些日志? 主机日志、平台日志、pod 日志、应用日志
  2. 这些日志在哪里? 主机日志:监控系统里面?自己要搭一个监控系统去获取? 平台日志:DCE 的平台日志在哪里?pod 日志:怎么获取?(pod 什么时候启动的、什么时候消亡、什么时候重启) 应用日志:业务交易日志
  3. 在不同的场景下,这些日志从哪里来的? 主机日志:自行产生,是否有监控系统 平台日志:DCE 给的 pod 日志:promethues? 应用日志:应用自行产生
  4. 我能通过这些日志得到什么? 主机日志:留给 IaaS 去做。主机日志可以帮助 PaaS 排错,规避风险,做容量规划 平台日志:监控平台状态 pod 日志:监控 pod、容器状态(CPU、内存、存储)->是否需要扩容 应用日志:应用交易质量分析预测
  5. 日志生命周期是什么?(日志怎么产生的、日志怎么消费的、日志怎么存储的、日志怎么备份的、日志怎么从备份中恢复)。
  6. 日志产生 日志存储 日志消费(采集-分析-报表)日志备份 日志恢复

技术层面:

  1. 架构 -> 技术选型 -> 常用解决方案(ELK/Splunk) -> 对比
  2. 你推荐哪个方案(框架选型、ELK?EFK?)?为什么?
  3. 部署架构 -> ELK,需要多少资源,这些资源能处理多少量的日志?

其他一些问题:

  1. 应用日志打日志规范
  2. 备份日志规范
  3. 其他一些很细节问题
  4. …..

写方案的套路过程:

Why -> 我为什么要做(业务目的是什么?)这个阶段不要想任何的技术实现和工具
How -> 我怎么做这个事情(业务处理逻辑、这个事情里面,有哪些事情。日志收集、分析,etc…)
|||
(这个阶段才需要考虑技术实现)
What -> 我用什么做,以及客户会得到什么?(日志预测分析系统,它是用什么什么做的,规模有多大,能处理多大的业务量)


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!