胡思乱想
市场定价问题
售卖内容由三个部分组成：
软件使用的License，包括软件使用期限约束和设备数约束
软件使用期间的技术人员服务（对于小客户可免费赠送）
软件使用以及SNMP技术的相关培训服务（对于大客户可免费赠送）
两套系统
License的生成和维护，需要另起一套WEB系统来管理。
那么这套系统应该同时承担了客户关系维护的功能。
销售人员可以在系统中维护客户的属性，设置License到期时间和节点数。一键生成License，由实施工程师导入客户系统。
License的生成可以采用JWT，将客户公司名称URI编码后作为密钥，加密节点数和到期时间。这样就几乎无法解密了哦。
技术选型取舍
我看好这个产品的前景，我认为这个产品需要有大而全的功能。
但是，产品仍需要尽快上线，电商园的客户既是我们的客户，也是我们这个产品的测试者。
最好是尽快做出核心功能后，将这套产品在电商园铺开，经过一段时间的磨合后，就可以作为一个更成熟的产品，杀向更广阔的市场。
几乎在所有的技术点方面，目前我只会实现1/3最重要的功能。其他功能设计预留接口。一切以尽快上线为目的。（但是如果产品某些指标达不到预期，我任然会选择推倒重来）
关于SNMP
厂商的管理信息导入，看来是长征一般的巨大任务。
我选择首先做华三的设备适配，有如下原因：
华三设备在安徽省市场占有率极高
华三设备文档清晰，MIB公开，开发支持较好
华三设备功能我更加熟悉，省去了硬件设备操作系统的学习成本
其实，任何一个厂商的设备，MIB库内容都数以万计。面对海量的MIB数据，我认为我们应该这样开发。
第一，产品中支持基础的MIB信息管理，例如端口状态，端口流量，Vlan状态，VRRP状态等等。将客户常用的功能内置。
第二，提供MIB导入和自定义解析功能。对于有特殊性能指标要求的客户，可以由我们的售后工程师现场配置MIB库。
两个后台
从前面的需求看来，显而易见，这套系统需要两个后台。
客户使用的后台，关心他们的设备运行状态，设备的维护。
售后工程师使用的后台，关心系统本身的状态，系统的维护（MIB维护，License维护等等）。
也意味着当这套产品铺开以后，我们将需要一支售后工程组成的队伍。
销售这样可以吗
一个售前 + 一个售后 + 一套彩页 + 低价(核心竞争力) + 售后出力 = 卖给民企成功
一个售前 + 一个售后 + 一套彩页 + 大量案例(关键) + 售前出力又出钱(关键) + 售后出力 = 卖给国企成功
简言之就是先低价吃民营企业，走数量。
案例多了就去碰国企，价格当然也相应的抬上去。
后端开发
django是不二选择，也几乎是python控制大型项目的唯一选择。
django还提供了一个好处就是，送了我们一套CRUD的后台。（工作量减少1/5）
测试驱动开发，否则系统庞大后就变成了维护地狱。
技术上是用pysnmp实现核心功能的，直接使用高级接口，性能不需考虑。（小客户设备少，大客户机器好）
前端开发
前端不会出大问题，但是前端可能更可能会出问题。
最保守的前端方案是html + css + js，文件引入的方式。百分百可以成功。
但是还是要选择npm打包的方式。因为现在都2019年了，技术上还是要有点追求才行。
万一真的驾驭不住了，就换成html重写，反正前端问题不会太大。
关于发布
如果可以的的话，直接做系统镜像包发布好不好？好
搭载到一个centOS7里面，内置好数据库，这样可行么？就这么干
这样发布有一个好处，以后方便转硬件，买工控机贴牌。
硬件卖出去价格高的撒
内置一套Django Mysql 自制探针
监控自身
产品部署之后，自动包含一个对自身主机的监控。
监控自然就是用我们开发的探针撒~
模板就用我们的主机监控模板哈（CPU/内存/硬盘/温度）
对的，我们是软件和操作系统一起提供的哦，所以不用考虑兼容性问题。
历史数据与趋势数据
历史数据就是每一次get请求的数据入库，数据量很大，可以保存两周。
趋势数据是每小时的平均值，系统自动计算完成。一年只有八千多条记录
可以保存很长时间（三年起步，十五年也无妨）
全网备份
这也是核心卖点之一
可以一键备份当前网络的状态
也就是我们的服务器还要起ftp的功能。让设备可以通过ftp把配置文件传进来。
当然文件的管理维护直接在web上做就好了。
系统中的FTP
文件目录/home/ftpuser
用户名ftpuser
密码suyun2016
ftp被动模式开放端口64000-64100 需要在vsftpd和防火墙上都配置
这些信息事不需要让用户知道的。在我们NMS系统和服务器交互的时候有就可以了。
用户甚至不需要知道我们内部有一个ftp服务器的撒
关于这个文档
就这么先放着，大家有什么想法就直接往这里面扔。等到了产品中期咱再好好整理。
Last updated