|
双向反馈
构建平台用户反馈沟通群组,第一时间接受响应用户的需求,重视“客户满意度”,并将客户反馈的问题,由专人进行收集汇总,每周发出平台质量问题周报,并组织开发运维力量,集中有效解决用户反馈的问题.这些问题,有技术性的,流程性的和体验性的,用户每一个问题的交互过程,通过沟通群传达给平台每一个用户.
体验优化
长期以来,在面向技术人员的系统 UI设计,用户体验是不好的,内部技术平台首要解决的是可用性问题.PaaS 平台需重视用户的体验,体验好也才能实现我们的 NoOps 的理念.试想一下,如果我们做了一个自己觉得很厉害的功能,而用户觉得不好用而弃用,那做的可能就是无用功.
也许有种担心,我们已经把所有的用户放在一个群里面,任何一个细节问题,体验问题,都会让所有用户知晓,平台维护者比较被动.我们的经验是,在 DevOps 文化下,平台的建设者(运维团队),平台的使用者(开发团队),都有面向业务最终用户价值交付的共同目标,都将以合作,包容的心态,共同推动平台的进步.
平台收益
平台收益情况,从四个方面表述,如图所示
- 质量
基础组件平台保障高可用,故障自动隔离.应用容器弹性伸缩,确保在业务变化中得到稳定的服务质量.平台提供自动化可用性管理方案,对业务质量形成有效反馈.
- 效率
执行 DevOps 理念,将研发,测试,运维全流程以自动化的方式整合,实现业务的快速交付.提供丰富的自助运维工具,系统,满足开发自助式运维需求,提高日常维护的效率.
- 安全
在网络安全和系统安全上,接入公司级安全体系,包括云防 DDOS,主机基线安全,主机漏洞检测,应用层引入公司的 WAF模块.在数据安全和 D/O 权限分离上,平台隔离开发人员登陆生产环境和生产数据库的权限,所有权限全部收拢在平台上,变更类操作自动引入工单,由运维介入审批.所有操作记录可跟踪.
- 成本
通过 IaaS 层的计算虚拟化,资源池,弹性伸缩等技术手段,提高系统资源利用率,减少硬件资源采购.通过自动化的技术手段,减少人力资源的投入一站式的运维管理服务平台,大大减少人员流动导致项目的交接成本,降低人力成本.
平台风险
PaaS 平台的风险,如图所示
????1. 容量管理
PaaS 平台的资源交付是完全自助的,不需要运维人员介入审批,IaaS 层的资源容量是有限的,从接入层,应用层,IaaS 层,构建全面的自动化容量评估系统,显得尤为重要.需要关注几个点：
- 资源调度
IaaS 层的资源调度器,一般都是静态的调度策略,是基于资源创建时间点来选取一台最优的节点进行资源新增.一般来说,我们的调度策略都会有一定的超额比例.但随着业务的发展,某些节点的负载会比较高,甚至出现资源不足导致系统宕机.
对于计算节点,我们有弹性扩展来保证业务可用性.但对于数据库如 Mysql,如果出现宕机,对业务影响非常大,一个 Mysql 宿主机,可能运行10个以上的实例,一次宕机影响几十个业务.
- 容量预警
对各类资源设置一个预警阀值是非常重要的.比如对于 Mysql 数据源,我们主要关注的是内存的分配,那么预警阀值=(已经分配内存)/总的可分配内存*100%,这个阀值随着资源池越大,可以调得越大.
- 容量预测
定期发布容量预测报告.如对计算资源来说,定期自动预测不同类型的套餐可创建的数量.同时,还需构建基于一段时间的趋势预测,以便及时发现平台资源容量突变情况.
????2. 隔离性
- 资源隔离
私有 PaaS平台,对 IaaS层资源,一般都是没有做资源隔离的.比如,像 Mysql 这种多线程的应用,单机跑多个实例,可能一个业务异常 SQL,就会耗尽宿主机的所有CPU资源而影响其他业务.因此,对于业务实例的质量分析,主动发现实例的质量变化,并及早介入优化,显得尤为中重要.
（编辑：应用网_阳江站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
