DIARY

继续推动运维标准化和流程化 标准化和流程化的落地，往往还会伴随着对已存在的系统部署方式进行迁移至标准化的操作。这其实要求我们在执行标准化和流程化以后的所有运维操作完全按照运维的标准和流程进行，对于执行以前的运维工作要进行迁移，目的是要实现所有系统和运维的标准、流程化。对于迁移，一般比较好的方案是：首先保留已存在非标准化系统，同时搭建标准化环境，进行已存在系统的部署并进行测试，测试无误后，与已存在非标准化系统并行运行，同时提供对外服务一段时间后，在评估，最后将已存在非标准化系统进行下线，以达到系统平滑得由非标准化迁移至标准化的目的。   建设CMDB 目前线上环境都跑在阿里云， 其它环境基本都是用友云cloudstack, 虽然开发者中心有资源池各主机的信息，但是目前服务器的管理还是依靠手工去登录处理，信息维护也是依靠用户接入或删除主机到资源池，具体信息维护起来麻烦且没有一个直观、统一去监控和配置管理的地方 要做的： 建立用友CMDB系统，结合阿里云SDK、用友cloudstack SDK，开发者中心资源池信息等，建立一个CMDB平台，第一步，能实现所有主机信息的实时显示和统计，如主机配置、资源使用情况、上面跑的应用。通过一个业务，如www.diwork.com, 能查出访问链路图， 如首先经过哪个SLB, 然后到哪台nginx, 再到哪个容器和哪个RDS等。 第二步，能根据业务的使用情况，对重要业务能实现根据资源池的负载来自动创建和销毁主机，如果负载高， 则自动创建按量付费的主机，如果负载低，则可自动销毁主机以节省开支。第三步， 能根据不同的业务制定不同的执行策略，如遇到CPU,硬盘报警、业务报错不可用，访问超时等，可被自动调用处理。 监控 监控是整个运维环节，乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供翔实的数据用于追查定位问题，分析业务指标等。 目前的不足之处： 之前用Nagios, ganglia, open-falcon, zabbix等作监控报警， 但是只能监控到主机基本指标， 在开发者中心大量使用容器自动分发部署后， 如何监控容器及k8s及各业务指标成为了重要需求， 目前主要监控报警是用prometheus系列来做的， 另外还有一些自写的自动化监控采集脚本去周期性执行并触发报警， 目前监控报警能做到主机基本指标、域名和api调用可用性和访问效率、容器及业务应用的可用性监控，发送到微信，友空间及邮件。 目前的问题是： 报警泛滥，没有达到很好的关联性分析，合并，降噪 没有很好的去做自动处理， 更多依赖于手工处理 现实情况出现的很多故障都并没有那么简单，大部分情况下，这种单一唯独的监控都没有办法很好的覆盖业务的监控需求，发现问题后不能快速定位，只能去一个个手动去查日志分析 下一步要做的： 制定统一的监控标准，推行统一的最佳实践，提供统一强大便捷的metrics lib库支撑。这样才能更容易的推进自动化进程，以及更高的监控指标覆盖度 1.坚持业务指标采集是代码的一部分原则不动摇，提高指标覆盖率 2.监控方式和指标要标准化，工具支撑系统化 原则1，没有人比模块的研发人员，更清楚其工作机制，更关心其运行状态，模块自身的可运维性就是代码功能的重要组成部分。每次业务逻辑部分的代码变更，都应该伴随着监控指标采集的相应更改。 有了原则1，还远远不够，没有好的工具和体系支撑，提高指标覆盖率就是一句空话。在运维层面，应该制定统一的监控标准，推行统一的最佳实践，提供统一强大便捷的metrics lib库支撑。这样才能更容易的推进自动化进程，以及更高的监控指标覆盖度。 谈谈监控标准化，标准如何定义？ 1.每个业务的每个接口，都要可被监控 2.每个接口的监控指标，必须至少包含： cps latency-50th/75th/95th/99th… error_rate error_count Read more…