客户案例——慧博云通有限公司
1.项目介绍
1.项目公司
关于慧博云通
本网站开办者为北京慧博云通软件技术有限公司，由北京慧博云通软件技术有限公司及其母公司慧博云通科技股份有限公司运营,
北京慧博云通软件技术有限公司为慧博云通科技股份有限公司的全资子公司。慧博云通科技股份有限公司成立于2009年，致力于成为一家国际化、专业化、创新型的综合信息技术服务提供商，主营业务包括软件技术服务、专业技术服务产品与解决方案三大板块。基于对各行业客户业务场景的理解，慧博云通以软件技术专业人才为载体，为国内和国际客户提供涵盖咨询、设计、开发、测试、运维等全周期的信息技术服务，助力企业客户产业数智化转型。
2.项目背景
客户有自主研发的EPM及CRM等多个企业管理系统及一些对外服务系统，并且一直为企业提供应用和服务的环境和工作负载支持，这些工作负载全部部署在企业IDC及Ali Cloud(阿里巴巴云计算)中。
在客户的EPM(Enterprise Performance Management)企业绩效管理系统，为企业内部雇员所使用，最近的更新中，通过用户反馈得知操作经常卡顿或者操作异常未响应等，研发人员对其进行了系统性排查，最终发现ECS(Elastic Compute Service)虚拟机的性能经常性达到瓶颈，CPU和内存短期内就存在超负荷的趋势，也直接导致了用户操作时，卡顿异常频繁。
此外，Ali Cloud提供的账单需要重新进行整合，花费财务人员大量时间，且需要一定技术学习成本。
3.项目目标
对现阶段客户EPM系统架构进行系统性分析，并设计出AWS架构解决方案，可自动化的实现性能扩展，不再需要人为的手动修改控制，为客户彻底解决服务器性能瓶颈问题。
对于业务迁移，需要实现无感知迁移，业务系统迁移变更时不可导致服务中断或异常等问题出现。
实现自动化管理及安全更新，减少研发人员在底层及环境上的时间，将更多的时间用于应用层面上，提高研发生产里。
2.项目解决方案
1.AWS架构图
在客户案例中使用Microsoft IIS, Microsoft SQL Server, Microsoft Active Directory作为核心服务使用。
1.Microsoft IIS
Microsoft IIS作为Windows Server中最稳定的Web Server，在客户案例中为EPM系统网站提供运行环境。为用户提供可访问的网站前端及数据交互。
2.Microsoft SQL Server
Microsoft SQL Server作为EPM系统最重要的核心组件存在，目的为存储EPM后端处理的大量结构化数据，为这些数据提供一个稳定安全，读写高效的存储数据库。
3.Microsoft Active Directory
Microsoft Active Directory在本案例中作用于安全模块，为Windows Server操作系统提供身份验证和权限管制功能，通过创建用户与组，分配相应权限和windows资源，达到安全的身份验证和授权流程。
4.EC2 Windows Server
部署Amazon EC2并使用Windows Server AMI镜像，可快速交付Windows Server操作系统，并使客户通过Session Manager或远程桌面的方式连接进行操作。
5.Amazon Directory Service
用于将Microsoft Active Directory 的 AWS Directory Service（也称为 AWS Managed Microsoft AD）与SQL Server数据库配合使用，以启用 Windows 身份验证。当用户使用加入信任域的 SQL Server 数据库实例进行身份验证时，身份验证请求将转发到您使用 AWS Directory Service 创建的域目录。
6.Amazon RDS for SQL Server
主要用于存储EPM系统的结构化数据，用于系统日常使用中的增删改查操作，为EPM系统数据提供存储。
2.API集成
1.IAM与Development
开发者在本地进行代码开发工作，生产应用为IDEA，编程语言采用JAVA或Python。部分开发作业需访问AWS API时，采用IAM临时Token的形式获取授权并进行AWS API访问。剩余则采用Secret Store提供的加密存储方法在代码中进行嵌入以实现程序运行自动解密并获取静态编程密钥，从而获取授权并进行AWS API访问。
在项目交付后，我司所使用的所有API集成方法和资源将全部删除释放，确保客户在使用EPM系统时AWS API的安全。
上图为IAM用户获取临时Token并访问AWS相应资源的流程图。图中开发账户中的开发IAM用户Alice现因开发原因需对生产环境中的S3及EC2资源进行访问，在AWS IAM服务检验role正确后，将返回Alice一个临时Token，这个Token将带有Amazon S3、EC2资源的写权限赋予Alice。在Token过期前，Alice都有权访问生产账户中AWS相应资源，直至Token失效。
3.Operational Excellence
1.部署CloudWatch Metrics以了解工作负载运行状况指标
我司将根据AWS CloudWatch Agent示例将其安装脚本执行命令用Systems Manager服务中Run Commands功能执行至EC2 Windows Server。完成安装后并对其配置文件进行指标模型配置，当配置结束后保存并重启CloudWatch Agent。返回至CloudWatch界面并在几分钟后刷新将获取到Agent发送的指标，其中就包括CPU RAM DIsk Network指标。
对于性能瓶颈或异常情况的判断和确认，我们使用CloudWatch Alarm功能创建需要的告警规则以实现对工作负载不间断的监控。大大减少了运维人员对大量服务器及工作负载的运维压力，并且可以集中管理这些规则，也使得运维人员可以将更多的时间用来构建自动化运维体系和其他工作。
创建Alarm并选择相应的CloudWatch Agent指标项，并设置阈值及触发执行动作，以及通知形式，确保告警出发，相关人员可以及时收到通知并进行处理。
我司已对工作负载设置了所有需要的Metrics和Alarm，例如：
a.根据EC2的 CPU RAM Disk Network等指标的持续监控，例如EC2 CPU在大于等于80%时触发即将超负荷的CloudWatch告警，再通过SNS主题通知到相关人员。
b.根据ELB的 请求、连接等指标的持续监控，例如ELB 请求大于100000时触发即将达到web应用瓶颈的CloudWatch告警，再通过SNS主题通知到相关人员。
c.根据RDS的 CPU RAM Conncetion等指标的持续监控，例如SQL Server Query在大于等于100k时触发达到应用性能高峰阶段的CloudWatch告警，再通过SNS主题通知到相关人员。
2.收集和分析工作负载运行状况指标
使用上述CloudWatch服务收集工作负载Metrics及Logs数据，并使用内置DashBoard(数据面板)功能分析指标及日志数据，并且以图表等方式展现以时间序列为单位的指标数据，了解工作负载运行状况指标将变得十分轻松。
在EC2 Linux Server中使用shell脚本，导出CloudWatch Metrics指标json数据并将其传输至S3日志存储桶进行加密存储。对相应的Log Group进行Export data to Amazon S3操作，将日志内容导入S3并集中加密存储。
3.运维赋能
我们向此项目客户交付涵盖如何监控工作负载、备份和恢复数据、修补和升级操作系统和应用程序组件，以及解决常见问题的《运维操作手册》、《常规及紧急故障处理指南》文档材料，以确保客户运维人员可以了解如何监控工作负载、备份和恢复数据、修补和升级操作系统和应用程序组件，以及解决常见问题。
将在操作移交前，我司将对客户进行为期一周的技术培训，方式为线上远程授课方式进行，内容包括但不限于持续运维方法、日常巡检及故障排除指导。
我司内部规定，在为期一周培训结束后，为期一月为客户运维技术支持窗口，尽可能的帮助客户熟悉AWS云上持续运维方法、日常巡检及故障排除等。
4.测试与验证
通过架构师编写的CloudFomation IAC代码模版，以CloudFotmation Stack方式部署测试基础架构，并且在Stack部署完成后，对其工作负载进行测试。在工作负载及EPM系统运行正常，SQL Server存储正常，一切都得到验证后便可完成部署测试及验证。
客户环境为两部分组成，一为开发与测试环境，用于日常开发和部署测试验证作业；二为生产环境，主要用于将经过开发和测试验证环节后稳定的应用部署至其中运行。
测试环境及生产环境在同一VPC不同私有子网中存在，目的为模拟最接近生产环境和实际场景，尽可能消除不同或不确定的因素，也为了和生产环境做网络隔离，确保开发测试环境与生产环境为两套完全独立隔离的架构。
首先将开发完成后的应用部署至测试环境运行，并在经过测试人员测试和验证后，将应用发布版本，由Devops通道推送应用至生产环境。应用程序将在本地进行开发并提交至Gitlab中，并由jenkins将源码拉取到测试环境中构建并运行，测试无误后，将利用NLB进行流量分发测试（金丝雀发布），再无问题后，正式推送至生产环境并运行，最后切换NLB所有流量至生产环境。
5.代码资产的版本控制
客户使用私有部署Gitlab仓库进行源码管理及版本控制（此Gitlab在客户案例之外的AWS架构中运行）。
客户开发者将在本地开发完成后，将源代码更新至Gitlab项目中，并由技术经理集中管理项目代码。
因为客户企业内部规定，不便在案例中透露代码资产及相关内容。
6.应用和工作负载遥测
CloudWatch Agent将收集工作负载及应用程序的日志文件并且作为CloudWatch Logs Group存在。主要日志内容为应用程序在运行时的Debug级别日志，可以帮助客户有效分析出应用程序故障及错误原因。
通过CloudWatch定义的相关Alarm，可以有效的观测工作负载性能指标数据和告警临界值，并且根据图表及数据做出合理的评估。
我司会在培训中为客户技术人员进行相关讲解，例如：
在发现读取或写入数据操作缓慢是，可根据CloudWatch Agent收集的有关于IOPS, 吞吐量及读写延迟指标数据，快速发现应用程序读写异常原由。
在连接或者搜索外部数据时缓慢且卡顿，可根据CloudWatch收集的有关于Package Sent，Package Receive等网络指标，快速发现应用程序网络异常原由。
相关应用程序为客户自行开发，不在此项目考虑范围内，所以相关日志内容客户将自行理解和处理。
4.Security
1.Identity and Access Management(IAM) 身份认证与权限管理
对于身份认证与权限管理客户在阿里云中使用IDaas服务进行身份认证与权限管理作业，但是由于功能的细粒度不够，导致客户无法对一些颗粒度很小的权限上进行操作，间接导致了出现因为权限分配问题所导致的安全风险。
在AWS中，我司使用IAM服务对客户架构中身份认证与权限管理做重新设计，确保客户在日常生产中可以正常稳定并且安全的对AWS资源进行操作和管理。下面为IAM服务配置的详细过程：
2.IAM体系设计
1.定义访问要求
为了确保身份账户的安全（Root Account），我们在建立IAM用户的基础上，不使用身份账户进行任何AWS资源创建与操作，并为身份账户配置MFA动态验证，提高身份账户的安全性。同时，我司也为特定的IAM用户配置MFA动态验证，提高IAM用户的安全性。以下为创建IAM用户的规则参考：
1. 为IAM用户配置强密码策略，采用16位全字符无规则静态密码，减少弱口令使用，所有密码打印至纸质材料封装保存，不保存在任何云上存储且不允许使用浏览器自存密码或私自保存在本地设备。定期轮换IAM用户的登录凭证；
2. 遵循最小特权授权原则，仅授权执行任务所需要的权限，最开始只授予最小权限。如有需要，向上级申报，审批之后，调整相关权限；
3. 同组人员工作性质相同并且向单独IAM用户授权不符合最小授权原则，所以授权对象为组，而不是单独IAM用户；
4. 业务系统目前部署在一个身份账户下，所有IAM设计全部基于一个账户下。
IAM设计图如图所示，因此IAM用户主要分为以下五个部分：
1. 主账户（Root Account）：作为默认账户及身份账户，在此账户上启动MFA，部署和构建IAM账户架构及用户组和用户。在AWS的日常交互中，使用其他用户凭证而不是默认主账户号；
2. 管理员组（Admins Group）：作为账户核心组存在，目的为管理账户访问权限及AWS资源；
3. 下级管理组（Managers Group）：作为下级AWS资源管理组存在，目的为AWS建立不同用户，分散AWS资源权限；
4. 开发者组（Developers Group）：作为AWS资源使用组存在，目的为调试与开发应用；
5. 慧博云通组（HYDSOFT-Group）：作为参与者查看AWS资源与账单成本信息，实时查看与监督我司操作AWS账户资源。
2.最小授权体系
IAM用户仅分配需要的AWS资源，屏蔽其他非需求资源，避免维护人员误操作导致业务中断等严重问题。如表所示为最小特权授权表：
针对每一个IAM账户，在创建前都会发出账户申请表以确认该IAM账户需要哪些授权，从而对IAM账户进行最小化授权操作。在另外需要新授权时，再次根据原表添加授权申请，以供管理员评估。
如下图所示，该用户只能读取hydsoft-static-resources-bucket S3桶中制定目录下的文件。
3.静态编程密钥
在架构及开发过程中，存在需要使用静态编程密钥的情况，使用Secret Store服务存储静态编程密钥，并在代码中创建相关方法解密加密数据得到授权从而进行操作，没有任何直接明文使用静态编程密钥的情况。并且，编程密钥将以生命周期的形式被轮换以确保密钥的安全性。所有编程密钥用户都严格按照最小化授权进行权限分配。
将AKSK等凭证存入Secret Store中，应用或工作负载通过IAM Role取得AKSK并操作AWS API，通过此方案可安全的调用AKSK。
使用IAM用户临时凭证的方式获取相应的AWS资源操作权限，在临时凭证生效期间均可调用具有相应权限的AWS API。
4.合作伙伴
我司负责项目的主要技术工作和商务合作，在通过和慧博云通的会议沟通后，客户表示可由我们直接进行技术工作。对于项目组成员严格按照职能分工及最小化授权进行AWS IAM用户的创建与权限分配。
2.网络安全
1.Virtual Private Cloud(VPC)
1.架构
我司创建部署慧博云通EPM项目专用VPC，并且采用多可用区不同子网部署服务以实现高可用架构，提高服务的可靠性及稳定性。web服务器负责web服务及前端服务的运行，后端及数据库全部位于专用的强隔离的私有子网里，通过ACL及安全组创建网络流量通信策略。
- VPC – 专用的EPM系统VPC网络，与其他项目和网络做出隔离，有效的区分项目。
- 可用区 – 共使用三个可用区(A, B, C)部署工作负载以实现高可用架构，可用区(A, B)作为生产环境专用区域，可用区C作为开发测试环境专用区域。
- Internet gateway(互联网网关) – 作为公有子网的网关，负责所有进出互联网的路由流量。
- NAT Gateway(网络地址转换网关) – 作为私有子网的“互联网网关”，负责所有不具备与公网通信的内网设备的路由流量。NAT Gateway与弹性IP绑定，作为所有内网设备在互联网上公有IP。
2.安全组
所有必要服务端口进出站IP地址均为必要，严格按照最小化访问进行设置。通常一个服务只对单个地址提供服务，所以设置子网掩码为/32的唯一地址；如有对多台内网实例提供服务的，则设置子网掩码为/16的内网网段地址。下图所示为最小化访问安全组设置：
无特殊需要，所有网络安全组所有规则仅为必要服务，一切无必要服务条目将立即被禁用且删除，通过对网络安全组条目的添加、删除与修改事件上报CloudWatch的形式，创建告警(Alarm)来及时了解网络安全组信息变动，有助于在出现异常操作时，修复安全组的设置。
对于默认服务，例如ssh(22), SQLServer(1433))等，进行安全的变更并保密记录，在无需运维管理时，将通过Network ACL(网络访问控制列表)对SSH保持禁用。在整个架构中，所有网络访问控制列表将对默认的所有流量开启禁用，并只授权必要服务端口和地址。
通过上述方法即可最大程度提高服务对外隐蔽性，使得必要服务或不必要端口不会轻易被外界所嗅探或攻击。并且在异常状态下，管理人员会第一时间收到来自CloudWatch Alarm的消息，从而进行异常处理。
如下所示，为客户案例部分工作负载安全组及NACL配置表截图：
3.数据传输
因慧博云通在AWS上托管的系统为EPM，客户大多在浏览器访问web端并登录进行使用，所以对外提供服务传输协议为http。
我司使用ELB、ACM与KMS服务集成使用，来确保所有的AWS服务端点对外连接全部且全程采用安全套字节(SSL)方式进行数据加密，有效阻止中间人攻击等数据劫持的安全风险。
图例为慧博云通AWS架构SSL加密及用户访问逻辑，从图中可见用户将使用SSL加密的HTTPS流量访问负载均衡器，LB接收到请求并转发至相应web服务器，对外暴露的端点全部采用SSL加密，内部除必要服务外均为HTTP协议流量。
WAF为AWS一款Web应用防火墙，可有效对来自互联网的恶意攻击进行拦截和记录，所有互联网流量将经过WAF策略检测后，安全的流量将被转发至负载均衡器或CloudFront并进一步转发给应用程序。如被WAF策略检测并命中的流量将被拦截并返回自定义的策略结果，同时将被WAF日志所记录。对于有效拦截日志将由安全人员审计并分析，从而做出处理，进一步提高架构及网络安全性，让恶意攻击无处遁形。
2.安全加密
我司使用Secret Store、Certificate Manager、IAM、KMS分别对慧博云通AWS架构中的RDS、SSL及AKSK等AWS资源进行加密存储。
- Secret Store – 主要存储静态AKSK凭证，确保凭证在有IAM角色授权的情况下被获取，从而调用相应权限的AWS API。
- Certificate Manager – 对SSL证书进行集中管理及操作，确保SSL证书的安全性，在慧博云通AWS架构中，与ELB、CloudFront结合使用，快速为服务载入SSL证书。
- IAM – 用于为日常开发者通过STS申请临时凭证，从而调用相应权限的AWS API。
- KMS – 主要用于S3、EBS、CloudTrail等服务的数据安全加密，多为服务默认生成的AWS托管KMS密钥负责数据加密作业。
6.Reliability
1.自动化部署
Terraform 是一个可以安全、高效地建立，变更以及版本化管理基础设施的工具，并可在主流的服务提供商上提供自定义的解决方案；Terraform不仅可以管理IaaS层的资源，如计算实例，网络实例，存储实例等，也可以管理更上层的服务，如DNS 域名和解析记录，SaaS 应用的功能等；更通俗的讲，Terraform 就是运行在客户端的一个开源的，用于资源编排的自动化运维工具。以代码的形式将所要管理的资源定义在模板中，通过解析并执行模板来自动化完成所定义资源的创建，变更和管理，进而达到自动化运维的目标。
我司在此项目中，大量使用Terraform IAC方式对基础设施进行创建与部署作业，IAC（基础架构及代码）的形式大大减少了维护与开发人员在创建与部署基础架构过程中的误操作概率并且进一步提高了部署的速度和效率。以极少的维护成本换来了稳定且高效的部署。
以上是通过结合AWS IAM AKSK及terraform对AWS EC2 VPC等资源进行创建与部署代码与执行截图，可看到通过此方法可以快速创建或部署AWS资源。
2.Disaster Recovery(容灾措施)
任何环境在一些特殊条件成立的情况下，也会出现意外故障，导致工作负载或应用程序不能够正常运行，从而直接影响业务，这种结果是任何企业都无法接受的，往往是最致命的事件。
因此容灾措施是合规中最重要的一环，容灾标准主要为下图中的两个核心指标为基准来评估容灾是否满足需求：
- RPO – 数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。
- RTO – 即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
我司与慧博云通开展了关于容灾措施的专门会议，并得出了初步的容灾需求，慧博云通所能接受的RPO为1小时，RTO为1小时，MTPOD(最大可容忍中断时间)为2小时。
根据客户需求，我司进行了容灾架构，经过验证和实际测试，证明此架构完全可以满足慧博云通的容灾需求。下图为容灾架构：
图中展示了在 Amazon RDS 上运行的 Microsoft SQL 数据库服务在单个区域中配置了多可用区部署模型。多可用区部署为数据库实例提供了更高的可用性、数据持久性和容错能力。
SQL Server核心服务恢复流程：
如果发生计划内数据库维护或计划外服务中断，Amazon RDS 会自动失效转移到最新的辅助数据库实例。此功能可让数据库操作快速恢复，而无需人工干预。主实例和备用实例使用相同的端点，作为失效转移过程的一部分，其物理网络地址将转换为辅助副本。
发生失效转移时，Amazon RDS 通过使用Always On 可用性组来支持 Microsoft SQL Server 的多可用区部署。
图中展示了在Amazon EC2上运行的 Web服务器在单个区域中配置了Backup服务备份模型。Backup服务备份为EC2实例提供了更高的可用性、数据持久性和容错能力。
EC2 Windows Server Instance核心服务恢复流程：
如果发生计划内服务器维护或计划外服务中断，可通过Backup服务自动备份的实例快照快速恢复最近时间点正常运行的实例状态。
根据相关CloudWatch Alarm设置，当实例检测状态失败时，将自动触发实例重启操作，如果在从气候，服务自启动并恢复正常，将不再通过backup服务进行快照还原。
基础架构恢复流程：
当一个可用区中服务因灾难性等因素不可用时，负载均衡器将自动将请求转发至运行正常的可用区工作负载当中，并在技术人员评估确认后，对其进行恢复作业（EC2 Instances，RDS），之后负载均衡器将正常转发请求至多个可用区中工作负载。
根据上述架构，我司工程师对容灾架构进行了模拟测试，并得到了可观的RPO及RTO。
容灾测试报告为慧博云通电子科技有限公司与我司共同进行的容灾测试后所总结的相关信息，报告中展示了关于RPO与RTO的数据：
- 应用程序恢复 – RPO: 15min RTO: 11min 03s
- 数据库恢复 – RPO: 10 min RTO: 6 min 39s
- 基础设施恢复 – RPO: 1h RTO: 44m 21s
在完成容灾测试后，我司与慧博云通进行会议沟通，容灾方案与架构得到了客户的认可及支持，在实际部署中也用到了这些容灾方案。
3.资源选择
1.弹性伸缩
对于业务高峰期的高负载及大流量，我司使用EC2 Auto Scaling服务对工作负载进行监控，一旦超负载或达到预期阈值，将会自动扩展工作负载实例并且在极短的时间内提供水平扩展的性能，这将在高峰爆发式突增的情况下，承受住高负载及大流量的压力。
对于业务高峰期结束，进入平稳运行期，水平扩展的工作负载实例也将随着阈值进行自动化释放作业，最大程度减少成本支出以实现弹性伸缩架构。使用Auto Scaling可以以最低的成本(时间与资金)完成工作负载的弹性伸缩。
2.指标分析
例如，在EPM系统初期运行期间，总是出现CPU负载持续过高的情况，经过我司和慧博云通沟通得知：
EPM系统中，有一算力要求很高的临时运行功能，每次运行时间不超过3分钟，但会被调用，调用频率适中。由于这一功能在运行期间占用了大量的CPU资源，导致EPM主系统卡顿甚至报错。
我司了解这一功能架构及原理后，决定使用lambda函数来支持它的日常运行，功能将被移至lambda函数，lambda将单独为其提供算力资源，并且EPM系统实例将不会被这一临时性算力占用CPU资源而导致主系统卡顿。更重要的是，Auto Scaling也不会被相关阈值触发而部署额外的EC2，造成资源冗余。同时，lambda函数将按照运行时间进行计费，相应的成本可谓是相当可观的。
在架构中，大量使用了CloudWatch指标进行工作负载的监控，客户定期收集核心指标数据并做进一步的分析，可以从数据中得出业务增长趋势和资源使用分布、状态等。
利用精准的指标数据可以非常快速的定位性能瓶颈以及所需算力等采购资源时需考虑的重要指标，从而为客户企业最大化节省尽可能多的资源冗余带来的不必要成本支出。
7.CostOptimization
1.CloudCraft
我司使用CloudCraft绘制客户案例AWS架构图，同时在此架构中设置资源配置细节，再通过budget功能与客户沟通意见，修改budget优化估算。下图展示了CloudCraft Budget (预算)功能截图：
将估算分析并整合后，将使用AWS计价器为慧博云通科技有限公司进行整体架构及服务计费估算。让客户能够清晰了解项目将产生的大概成本，从而评估项目是否合适等。
2.AWS Pricing Calculator
我司在使用 CloudCraft 基础上使用 AWS Pricing Caculator 对于一些特殊服务进行更加细致的数据优化，从而得到更为精确的估算。下图为AWS Pricing Caculator TCO估算：
