前言
CNUTCon连续2年都是以docker容器为主的技术峰会，今年改名全球运维技术大会。你可能会想，我可能去了一个假的CNUTCon，其实，不是。CNUTCon一直专注于运维，而前两年比较docker比较火，所以主推docker；而这两年人工智能比较火，便主推AIOps。
本文融合了一些本人思想，如有理解错误，请指正，谢谢。
开篇
首先，是InfoQ主编徐川先生指出本次主题为《智能时代的新运维》，运维平台的演变逐渐由工具化、web化、自动化转向智能化。
那么AIOps是什么？
AIOps：通过人工只能的方式，进一步提高运维效率，包括运维决策、故障预测、问题分析等。
AIOps的数据来源：
1、 业务
2、 操作系统
3、 运维平台
4、 硬件
AIOps的应用场景：
- 性能优化
- 故障分析
- 预测硬盘故障
- 流量调度
等
AIOps的落地企业
第一场：AIOps-百度的思考与实践
主讲：王栋，百度基础技术体系主任架构师，听主持人介绍他是清华大学博士生，曾在谷歌工作7年，14年加入百度。
王栋老师
百度的业务繁杂这个我们都清楚，但是看到百度前几年运维平台ui也是那么简洁，我还是蛮惊讶的，原来大公司也会有一些比较low的界面。当然啦，作为程序员不该以颜值来判断系统的好坏，背后的代码及架构才是我们学习的地方。
GUI运维
大概用了十年，百度基础运维平台从GUI->API->智能运维平台。
智能运维平台
百度在运维中统一了很多环境，王栋老师借用始皇帝的书同文、车同轨、行同伦来定义百度AIOps的出发点。不得不说，在我的工作过程中，我觉得这个的确很有必要，不同的服务器机房、集群如果不能够统一，会浪费大量的维护工作。而反复的造轮子也会造成差异越来越大。
王老师先将运维自动化分为5个等级，目前百度在3-4的过度阶段。
在王老师的理念之下，建立运维体系下，极大的减少了运维人员流动造成的交接成本，每位同事都可以通过运维知识库去解决问题，每位同事都可以创建运维知识库，并且平台会根据schema管理起来，使得维护、交接都很容易。
我觉得百度毕竟是大企业，有力气做那么的活，而对于中小企业，先把运行环境统一起来，再去折腾书同文、车同轨吧。
当然，百度还有一套故障仿真系统，可以轻松摸你各种硬件、软件上的故障。的确，对于开发人员而说，很多时候，不容易制造硬件故障的条件来检测自己的脚本是否ok，毕竟现在服务器都比较稳定，很少出问题。而有了这套系统，可以对自己脚本反复测试。
第二场 DevOps知识体系与标准化的构建
主讲：张贺 南京大学 软件学院教授
说实话，能力有限，我听得不是很懂，但是现场还是有很多小伙伴去找他交流，这里我就选几张图作为本场介绍
第三场 从自动化到智能化的阿里运维体系
阿里在探索智能化的道路上走的还是比较远的，从阿里在监控领域效果对比图中可以看出误差极小。
当然这期间阿里组织架构也发生了一些改变。
- 工具研发团队+运维团队 ->
- 工具研发同时做运维 ->
- 工具研发和运维融合 ->
- 日常运维交由研发，彻底DevOPs
曾经我在公司内部提出将部分运维交给开发的思想，刚开始很多反对声音，但面对各种各样，运维很难解决的问题，我还是硬着头皮推进这件事情，当听到阿里的这段组织结构改变，让我更加坚定了我的理念。当然啦，我们公司自部分运维交由研发后，效率高了很多
他吐槽在运维过程中，经常由于各种情况，变更机房，他们不得不去解决快速迁移机房带来的各种问题，他还给我们开了个玩笑“不要让迁移机房成为阿里的核心竞争力”。
我作为阿里云的忠实用户，看着阿里云从创立时几个开放节点，一直发展到现在节点遍布全球，看着这庞大的后台，使用智能化，机器学习去解决了，机器比例问题，还是给与我们很多参考价值。
携程容器云优化与实践
在不了解运维人的开发人员眼里，他们能看到的只是水上的服务，而水下是运维人员不断建造的地基，而强行将这些水下的知识传授给开发是不明智的选择，所以携程尽可能将其封装，尽可能使开发无需熟悉水下的基础。
然后携程自己研发了一套Framework，处理了网络、cpu、日志连续性等问题。
对于cpu核心的回收以及分配，携程做到合并请求来处理单次释放核心不足以提供下一次需求的问题。
当然携程还有一套监控体系，来监控各个宿主机器物理机及docker容器的健康检查。
还是那句话，对于小公司自研Framework层是一个不明智的选择，而携程自研的动机是什么呢？
- 轻量化，专注需求
- 兼容性，适配原有中间件
- 程序员的天性，改不如重写。
携程还提出一个理念：谁开发，谁运行。
这一点其实，我没太懂，这里的运行具体指什么，生成环境的运行吗？我没好意思问主讲老师。当然，我觉得生成环境运行还是交给运维部门出问题的可能性小点。
我们都知道在tomcat作为主进程的docker体系中，tomcat启动失败，则容器停止。为了解决这个问题，携程给每个每个容器中增加了多个进程，而不以tomcat作为主进程，此时进程列表如下：
docker容器中没有hook，而携程去做了一个进程来处理hook问题。
携程还提到一个问题，有些时候java开发会在线程中读取cpu核心数来确定开的线程数量，而在docker容器中，得到核心数目是物理机的数量。造成了创建过多线程造成资源耗尽，程序OOM。当然了，采用cpu quota，java也无法获取准确的cpu数量。
于是他们在运维中，默认推荐配置，但支持开发复写配置，对于那些不可被修改的配置，采用强制配置。
dockfile优点：
- 不同的测试环境不同需求
- 课定制image
- 简单易懂，上手快
暴露的问题：
- 无法执行条件运算
- 不支持进程
- 如何维护dockfile
- 就是个后门，环境标准化被破坏
于是携程以plugin插件的形式去解决配置问题，我觉得问题有点被搞复杂了，大部分场景可能不需要。
腾讯游戏容器云平台的演进之路
腾讯入场就给我们说，腾讯绝大部分的应用都运行在容器里，大概23万+的处理器，但是在交流期间，当我们听众提出具体有哪些游戏、哪些模块运行在这个体系下。我们的讲师显得有点藏着噎着，随后我们这位听众直接问，王者荣耀是不是也在里面，腾讯给的回答是，他负责的是平台，具体业务他不过问，就这样成功的绕过了问题。
不得不说，如果这组数据是真的，腾讯在容器应用上还是蛮拼的，数万台物理机组建出的容器平台，性能之强大无法想象。
毕竟有些时候机器学习需要耗费大量的GPU，所以在部分服务器中GPU也成为了核心。
腾讯在容器ip影响传输效率的问题中，给出了一个解决方案，我的理解是，他们从网桥形式分配ip地址转向为物理网卡分配容器后，再分配ip。来使得网络中间层更精简，来提高传输速度。但是，就我而言，在传统网桥的生产环境实践中，暂时并未发现网络传输上存在性能问题。当然，毕竟是腾讯，像王者荣耀这种游戏，对网络环境、延迟要求很高，也可以理解。
腾讯的监控系统：
容器日志问题汇总，统一显示平台。
当然，腾讯也有自己的私有镜像仓库平台，而且使用了P2P方式分发镜像，我想也是为了加速同一区域机房部署速度吧。
华为使用Docker支持系统容器的优化实践
华为做了一件很大的事，居然把容器作为系统级容器，类似于虚拟机容器，也可以理解把容器改为虚拟机运行。
系统容器可以像虚拟机一样使用，但是资源消耗上，肯定比正常容器好大。
动态挂载资源
使用SELinux系统：
多租户KUbernetes实践：从容器运行时到SDN
kubernetes插件机制
Kubernetes插件示例
HyperContainer速度、兼容性等和docker相比，都毫不逊色，甚至超越了原有的框架。
实践中的经验：
总结
说实话，听了一天感想特别多，整理了那么多，也有点累了。也考虑到想让大家早点看到这篇文章，所以先发出去，明天再继续写。