ATAM
本文结合笔者的实际工作经验，主要论述软件系统的架构评估。首先分析了软件架构评估所普遍关注的质量属性并阐述了其中的性能、可用性、安全性、可修改性的具体含义。整个系统采用了前后端分离的设计，在架构设计完成之后，使用基于场景的架构分析方法中的ATAM架构权衡分析方法对系统作了评估，并详细描述了其评估过程，项目评估小组经过对项目的风险点、敏感点和权衡点的讨论后生成了质量属性效用树。目前系统已稳定运行一年多，从而验证了该项目采用ATAM架构评估保证了系统的顺利完成。
架构评估是软件开发过程中的重要环节，在架构设计之后，在系统设计之前，目的是为了评估所采用的架构是否能解决软件系统的需求，但不是单纯地确定是否满足需求；
在软件架构评估中的质量属性有：性能、可用性、可靠性、安全性、可修改性、功能性、可变性、互操作性等。
性能指系统的响应能力，即经过多长时间对事件作出响应，衡量指标有响应时间、吞吐量等，设计策略有：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等；
可靠性指软件系统在应用和系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力，衡量指标有MTTF、MTBF，设计策略有：心跳、ping/echo、冗余、选举等；
可用性指系统能够正常运行的时间比例，用2次故障之间的时间长度或在系统出现故障时系统能恢复的速度来表示，衡量指标如故障间隔时间，设计策略同可靠性；
安全性指系统在向合法用户提供服务的同时能阻止非授权用户使用或拒绝服务的能力，衡量指标有保密性、完整性、不可抵赖性、可控性，设计策略有入侵检测、用户认证、用户授权、追踪审计等；
可修改性指系统能快速地以较高的性能能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过考察这些变量的代价衡量，设计策略有接口-实现分类、抽象、信息隐藏等；
常用架构评估方法有：基于问卷调查的方式、基于度量的方式、基于场景的方式，基于问卷调查，要求评估人员对该领域熟悉才能评价好问卷中的架构方面的问题，其评价过程具有主观性；
基于度量，需制定一些定量标准，并制定质量属性和度量结果之间的映射，其评价虽较客观，并要求评估人员对架构熟悉；
基于场景，分SAAM、ATAM、CBAM成本效益分析法，首先要确定应用领域的功能和软件架构的结构之间的映射，然后设计用于体现待评估质量属性的场景（4+1视图中的场景），最后分析软件架构对场景的支持程度，要求评估人员对领域熟悉又对架构熟悉；
在使用ATAM进行评估时，我们根据项目需要成立了项目评估小组，主要成员有：用户、项目决策者、架构设计师、开发人员、DBA、运维人员、测试人员等项目干系人，我在其中担任系统架构师。架构的评估经历了描述和介绍阶段、调查和分析阶段、测试阶段和报告阶段，下面我分别从这4个阶段进行介绍。
在描述和介绍阶段，由于项目评估成员有部分对ATAM并不熟悉，首先在会上介绍ATAM方法，它是一种基于场景的软件架构评估方法，对系统的多个质量属性基于场景进行评估，通过该评估确认系统存在的风险，并检查各自的非功能性需求是否满足。客户也阐述了系统的目的和自己所关注的一些事项，如项目是通过管理好基础数据最终将各业务开发小组、运维小组的工作自动化，监控软硬件资源是为各小组快速定位问题、解决问题提供支撑。客户所关注的一些问题，如DB组关注的告警即时性和应用运维组关注的CD模块的可用性。最后我描述了系统总的架构设计和各个模块的功能。
在调查分析阶段，不同的需求方基于各自的考虑提出了各自的要求。其中领导提出，该系统公司内各岗位技术人员都要用到，需保证其7*24h可用，至少要保证监控的连续和告警的及时推送，有问题需在1min内恢复；DB组提到若某个库连不上，他们需在2min内收到告警；应用运维组提出至少要保证在工作日发布高峰期的时间段内CD功能是可用的，同时提出非工作时间段内在线上正常发布时功能性方面若有异常应能找到值班人员予以配合排查问题；产品组提出，为维护CMDB中数据的准确性，该基础数据与项目组的jira系统数据有交互，如有变更需确保在1人天完成；经过总结我们获得了系统的质量效应树，依次为可用性、性能、可修改性。
针对这些场景我们分析了项目开发过程中的风险点、敏感点、权衡点、非风险点。该项目中存在的风险点：若监控软件自身发生故障将监控不到各软硬件资源的当前状态，将不会发送告警信息给运维或开发，相关责任人将不能提前预知业务要发生的问题；网络如果有波动，可能会给责任人发实例宕机相关的告警信息或告警恢复信息。敏感点有如果用户将告警级别调低，可能会有大量的告警信息发出，这将会影响告警程序的性能，同时用户会收到大量告警，会给用户带来困惑不知道问题的重点在哪或主要问题的根源在哪；非风险点：应用运维组提的非工作时间内功能性方面有问题要能找到对应人员，这个需求是合理可行的。
在测试阶段，经评估小组集体讨论，确定了不同场景的优先级如下：系统的可用性最高、性能其次、可修改性较低。在保证系统可用性方面，web端的负载均衡上使用F5双机热备技术；在监控模块上使用集群模式1台主zabbix_master、5台zabbix_proxy，对zabbix_master的库采用主从+读写分离，前端web页面的监控数据仅从slave库上获取，这样即便1台设备出问题，不会影响整个监控。在性能方面，web端的应用服务器后端采用4台，这样可有效提高并发能力，并有一定的高可用能力。在可修改性方面，主要涉及到管理方面人员调配，领导同意在需求紧急情况下可适当加班配合。
最后形成了评估报告，经过对架构的评估，确定了系统的风险点、敏感点、权衡点和非风险点，最后以文档的形式表现。其包括的内容有：架构分析方法文档、架构的不同场景及各自的优先级、质量属性效应树、风险点决策、非风险点决策及每次的评估会议记录。
