[Day 1]上海CNUTCon全球运维技术大会2017实录

前言

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相比，都绝不逊色，甚至超越了原有的框架。

实践中的经验：

总结

说实话，听了一天感想特别多，整理了那么多，也有点累了。也考虑到想让你们早点看到这篇文章，因此先发出去，明天再继续写。