菊厂MDE的生存经验–方案对比

万丈高楼平地起。
无论对做技术方向、还是做管理方向,这样都有吸引力和成就感。但以现在的年代,对于一般的业务,无论业界、还是公司内部,都有一些现成的技术方案、平台可供选择。因此,工作中主要的问题不在于无方案可选,难处在于选择太多,需要具备一双慧眼从中选择一个既匹配业务、匹配团队、又匹配个人的方案。
那么,现在手头有用户的需求,也有一些可选的方案,怎么从中选择一种方案呢?
从如下几个维度进行分析:

  • 业务场景
    业务场景以我方项目为准,可以从客户诉求、业务价值、原始需求出发,整理一个相对完善的清单。如果可选集中的方案有成熟的交付案例,则可以从中提取各方案对应的清单。
  • 业务功能
    对业务场景清单的细分和分解,需要考虑客户的特点、我方项目的交付特点,整理得到功能清单。同理,可以按照类似的格式,对可选集中的方案做一次梳理。
  • 业务规格
    和功能稍有差异,主要体现容量、速度、效率等方面的要求。这类要求需要耐心和客户沟通、确认。但在MDE层面,直接面对客户的机会相对要少一些,通常可以从前述清单出发,整理出规格清单,和架构师、SE确认即可。同理,需要针对可选集中的方案,梳理相同的清单。
    举个例子,比如作为一套管理系统,要求必须容纳N个账号,其中M个账号允许同时在线。
  • 技术方案
    对于前述整理的功能,对技术组合的要求,梳理后整理成清单。同理,需要针对可选集中的方案,整理对应的清单。
  • 技术规格
    使用对应的技术方案,为满足前述的需求,可以达成的规格,需要使用的资源等,可以从场景出发,整理成几份清单。同理,可选集中的方案,由于已有成熟应用的案例,可以直接从案例中提取。
    举个例子,比如报表系统,为满足时效性的要求,可能会有不同的技术组合,那么在时间、资源方面有不同的要求,相对应的,在技术层面可以梳理出不同的规格要求。
  • 收益/代价/风险
    我们期望方案,一方面可以匹配用户的需求,另一方面照顾项目团队的感受。 满足要求的方案不能说不存在,只是多数时候需要在某些方面做一定的妥协。那么,为了满足前述要求,需要在收益/代价/风险方面,做不同的选择。因此针对可选集中的方案,从需求出发,梳理清单。

最后一步,汇总清单,罗列关注要点,从可选的方案中,挑出匹配程度最高的方案。

总结一下,关键字有,客户需求,需求场景,可选方案,重要的关注点。

发表在 工作总结 | 标签为 , | 留下评论

回归分析

回归分析,一种研究相关的工具。
相关关系,可以描述为 y ~ x
因果关系,可以描述为 y = f(x)
x是变量,y是因变量。
用业务语言描述,y是实际业务的核心诉求,而x是解释y的相关因素。
而回归分析的目的是通过已知的(x,y的信息,寻找其中的相关关系,进而解释现在,预测未来。

回归分析过程中的重要工作:

  • 识别x中的重要因素。
  • 判断相关性的方向,比如正相关或者是负相关。
  • 识别x中因素的权重,进而判定x中各因素的相对重要性。

具体到实际场景,回归分析有如下几种变化:

  • 线性回归,普通线性回归,因变量取值于连续空间。
  • 0-1回归,因变量取值的集合只包含0和1。
  • 定序回归,因变量取值的集合包括有限的值,并且集合中的成员之间无法定义明确的距离。
  • 计数回归,因变量取值的集合包括的都是整数。
  • 生存回归,类似线性回归,但取值均有截断的特点。

正确使用回归分析,需要对业务或者问题有深刻的理解。

发表在 统计 | 留下评论

从GC日志中可以得到哪些信息

GC日志中包含的信息有如下:

  • GC操作的时间点
  • 当前GC操作距离Java应用启动时刻的时间
  • GC操作的类型,Full GC或者GC
  • GC的触发原因,比如System.gc()
  • 堆的变化,包括年青代、年老代、元数据区、Java堆,在本次GC操作前、后及总占用空间
  • 本次GC操作花费的时间
  • 本次GC操作花费时间的分布,分别为用户态、系统态、总时间

从上述信息中,可以进一步提取如下信息:

  • 两次GC操作之间的时间间隔
  • 两次Full GC操作之间的时间间隔
  • 一段时间内的GC次数,GC操作总体花费的时间,单次GC操作平均花费时间,以及最大值和最小值
  • Full GC的次数,总体花费时间,单次Full GC操作平均花费时间,以及最大值和最小值
  • 两次Full GC操作之间,GC操作的次数,以及平均值
  • 老年代的使用率,占用的空间,变化趋势
  • Java堆的使用率,占用的空间,变化趋势

Java应用运行在JVM之上,GC操作是JVM在运行时触发的一类行为。从技术上讲GC不可避免,但从业务角度,我们期望计算机的CPU、内存等资源尽可能的用于业务自身,因此期望相关操作尽可能使用较低的资源,而有较高的吞吐量。

发表在 Java, JVM | 标签为 , | 留下评论

Redis安全的笔记

Redis is designed to be accessed by trusted clients inside trusted environments.

上述说明来自官方文档Redis Security。因而在实现针对Redis的安全保护方案时,需要付出更多的代价。 考虑因素包括系统安全、网络安全、软件安全、应用安全。

系统安全

  • 操作系统及相关软件及时升级至最稳定版本。
  • 及时修复操作系统及相关软件的安全漏洞。
  • 关闭不相关的服务。
  • 禁用不必要的端口。
  • 卸载不相关的软件,如编译器。
  • 清理未使用的账号。

网络安全

  • 推荐绑定在本地回环地址,即只允许本机访问。
  • 避免直接对Internet暴露服务。
  • 绑定到指定IP,避免使用通配方式暴露服务。
  • 使用非标准端口对外提供服务。
  • 定义黑名单和白名单,使用iptables控制访问来源。

软件安全

  • 推荐使用Redis当前的稳定版本。
  • 及时升级Redis的版本。
  • 清理不相关的文件,如安装Redis时使用的源码包、样例文件、未使用的工具等。
  • 禁止高危命令,使用样例:
    rename-command CONFIG ""
  • 重定义必须使用的高风险命令,使用样例:
    rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
  • 指定内存的使用上限,避免影响应用和系统的稳定性。
  • 指定客户端最大通信链接数,规避DoS攻击。
  • 指定客户端通信链接的闲置时间的上限值,当客户端链接空闲时间超出上限后,将自动关闭链接,避免占用过多的资源。
  • 禁止将数据文件保存至系统分区。
  • 禁止将日志文件保存至系统分区。
  • 控制Redis软件、配置文件、日志文件、数据文件等的系统权限和属主,避免信息泄漏。

应用安全

  • 使用单独的操作系统用户运行Redis服务。
  • 关闭Redis运行用户的登录权限。
  • 禁止在Redis中保存敏感数据。
  • 禁止在命令行中使用Redis的口令,避免攻击者通过查阅history得到口令。
  • 合理使用日志切割工具控制日志文件的大小和数量,避免中断业务。
  • 对访问Redis的客户端进行认证,并且定期更换认证口令。

其它措施

建议通过修改对Redis的源码,提供如下特性:

  • Redis客户端在传输口令时,使用传输密钥对口令进行加密。
  • 传输密钥支持更换。
  • 在Redis的配置文件中,加密存储口令。
  • 存储密钥支持更换。
  • Redis客户端与Redis服务端之间定义加密的数据传输通道。
  • Redis客户端与Redis服务端之间实现双向认证。
  • Redis服务端认证客户端时,定义认证操作的超时时间,规避慢攻击。
  • 从使用场景将Redis的指令区分为管理用途和数据访问用途。对于管理类的指令,仅允许在Redis服务端本地使用;对于数据访问类的指令,可以在客户端使用。

参考资料

发表在 Redis, 数据库 | 标签为 | 留下评论