云服务管理与运维的定义：是指一个组织提供给给客户的IT和云服务的计划、设计、交付、运维和控制等一系列活动。服务管理包括对应用和服务的运维，当应用被部署到生产系统，就必须根据设定的 SLA （Service Level Agreement）和 SLO (Service Level Objectives) 对应用的可用性及性能进行监控。
随着开发的敏捷化，云服务管理也应该向敏捷转型。转型可以从几个方面入手：
- 组织：引入相对于传统 IT 开发组织的新型组织，开发和运维要越来越紧密结合，其实就是 SRE。
- 过程：在云世界要尽量做到自动测试、集成和发布。变更管理必须改变到自动化的路子上，因为发布速度可能很快。
- 工具：引入新的工具，更加快速地定位问题，例如 ChatOps。
- 文化：推行一些新的文化，例如无责任根因分析，对于系统所产生的故障进行深度的分析，但是并不追责，从而可以吸取教训却不影响士气。
^^^以上是两年前的一点点关于云服务管理和运维的笔记，一直保存在草稿里，没什么特别的。本来想展开写一篇，居然一直没有下文了。甚至现在也没有心情了，就此作罢吧。
不过可以值得一提的是，此前接触过一点 AIOps 相关的事情，思路一直在传统的机器学习领域，例如利用算法学习机器的一组监控数据（内存，I/O），找到服务的稳定状态，而当某个异常状态来临时及时（或者提前）向运维人员报警。但是这种思路很快碰到的实际问题还是蛮多的，首先如何定义稳定的服务状态和异常的服务状态，从机器的角度资源的使用有时可能是随着用户使用量爆发的（例如秒杀），突然的爆发必然使得资源使用曲线突然变化，但只要没有超过机器的资源限制，通常服务还不会出问题；利用算法预警的目的往往是要提前预测问题的发生，实际情况是算法预警的时候，系统还是好的，运维人员此时往往什么都做不了。比较折衷的做法可能是类似于像可能内存泄漏这样的问题，当内存使用超过某个阈值时重启服务，但好像这种做法又不需要机器学习这么复杂。
所以成本折衷的方法往往还是利用运维人员的经验，将经验值做到自动化工具里，达到某种程度的自修复即可。当然，对 AIOps 来说也不是什么都做不了，生成式 AI 的出现让我们可以换个角度，通过对历史数据，运维手册，根因分析等数据的利用，是的报警到达时能够快速帮助运维人员理解目前正在发生的问题并作出修复决策，从而可以极大缩减恢复系统所需要的时间。
从我理解来看，虽然生成式 AI 在很多能力方面（记忆、自动驾驶）超越了人类，但是在大多数还是没办法替代人。它应当尽可能当做生产力工具来使用，降低人类的重复劳动，提高生产力，人类的生产力会被它提升一个等级，应当还无法完全替代人。不过之前我感觉 AI 在创造力方面应该无法企及人类，但现在来看在艺术创作，绘画生成、照片生成、音乐谱曲、视频制作等领域确实产生了不少好的作品，AI 能力的发展可谓是突飞猛进日新月异。所以 AI 治理伦理会是当下比较值得探讨的话题。