程序员应知应会之自动化运维那些事儿

对于一个开发人员来讲，可能运维并不是自己的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。

而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。

一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。

反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。

所以今天我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。

一、自动化运维的概念

随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。

所谓自 动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统724小时高效稳定运行 。这是所有业务系统运维的终极目标。

按照运维的发展成熟度来看， 运维大致可分为三个阶段 ：

（1）依靠纯手工，重复地进行软件的部署与运维；

（2）通过编写脚本，方便地进行软件的部署与运维；

（3）借助第三方工具，高效地进行软件的部署与运维；

二、自动化运维需要解决的问题

自动化运维通常来讲，需要解决以下几个问题： 自动部署配置、风险事前预警、故障事中解决、和故障事后管理 。

三、自动化运维的常用工具

自动化运维常用的工具包括以下几种：

1、Ansible

ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

ansible具有如下一些特性：

(1)模块化：调用特定的模块，完成特殊的任务。

(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。

(3)支持自定义模块，可使用任何编程语言写模块。

(4)基于python语言实现。

(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。

(6)安全，基于OpenSSH

(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。

(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。

(9)较强大的多层解决方案role。

2、Chef

Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。

Chef 主要分为三个部分 Chef Server、Workstation 以及 Chef Client。用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上面实施安装和部署工作。所以，对于 Cookbook 地编写在整个自动化部署中起到了重要的作用。

Chef Server 包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。

Workstations 用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。

Chef命令行工具 是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。

Knife 用于与ChefNodes进行交互。

Test Kitchen 用于验证Chef代码

Chef-Repo 是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。

Nodes 由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes 是一台机器，例如物理云，云主机等。

Chef-Client 负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。

Cookbook 是Chef 框架的重要基础功能之一。在 Chef Server 对目标机器做安装部署的时候，是通过 Runlist。而 Runlist 里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook 上。而对于 Cookbook 来说，其中包含了多个组件，我们可以将 Cookbook 简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata 等信息。这些信息用于配置我们的目标机器。

3、Puppet

puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。

客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；

Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；

Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；

Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；

Puppet服务端再把客户端的执行结果写入日志。

4、Saltstack

SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。

在saltstack架构中服务器端叫Master，客户端叫Minion。

在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。

saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master 服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。

saltstack提供如下一些功能：

（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。

（2）配置管理/状态管理 ：（描述想到达到的状态，saltstack就会去执行）

（3）云管理(cloud)：用于管理云主机

（4）事件驱动：被动执行，当达到某个值会自动触发

这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：

运维工程师一般有系统运维、网络运维、运维开发、数据库运维、云运维等方向，今天主要介绍系统运维工程师所需要具备的一些技能和考证方面。

系统运维工程师必备技能

系统运维工程师不仅需要有Linux基本操作技能，还应该会服务器硬件、以及企业里常用的双机集群、Windows、VMware、数据库等技能，这样才能有担任合格的系统运维工程师。

需要特别注意企业里物理机都是用双机集群，一定要掌握双机集群的技能，包括Linux双机集群、Windows双机集群、Oracle Rac数据库集群、SQL Server数据库集群等。

前几周有人问我，如果有一个环境中给你10多个交换机和路由器，应该如何配置。这是一个很好的问题，关键不在端口安全、Port Channel、STP、和路由的配置，而是在于针对终端应用服务特点选择相应适合的网络架构。

近十年来，虽然云服务的扩展性需求促进了相关解决方案快速发展，然而数据中心常见的网络拓扑仍然可以归纳为两种：传统的三层网络架构，和Leaf-Spine二层网络架构。

传统的三层网络架构由三层交换机组成：即访问层，聚合层(有时称为分发层)和核心层。服务器连接到其中一个边缘层访问交换机(常称Top of Rack Switch，或 TOR Switch)，聚合层交换机则将多个接入层交换机互连在一起，所有聚合层交换机通过核心层交换机相互连接。核心层交换机还负责将数据中心连接到Internet。传统的数据中心过去采用的就是这种三层架构。

下图是我参与优化设计的有数万台服务器的传统数据中心网络架构示意图。

在这个拓扑中，除了经典的三层（分发路由器，网络分区汇聚路由器，服务器接入交换机）外，核心层还包括了： WAN核心骨干路由器，WAN发路由器，WAN优化加速器，LAN核心路由器，外部Choke路由器，Internet边界路由器，Transit，防火墙，用于联接数据包分析器的Network TAP。网络负载均衡器放在了聚合层。另外还有一个专用的OOB接入层，用于设备维护管理。

三层架构虽然容易部署、易于诊断，但是其已无法满足日益增长的云计算需求。三层架构面临的主要问题包括：低可扩展性、低容错性、内部服务器之间横截面带宽低、较高层超额使用（Oversubscription）、高层次的拓扑中使用的大型模块化交换机成本非常高。

我过去常采用以下这几个方法缓解三层架构中网络分离问题：

(1)、PVLAN: 专用VLAN，也称为端口隔离，是计算机网络中的一种技术，其中VLAN包含受限制的交换机端口，使得它们只能与给定的端口通信。这个常用于后端的NFS网络。

(2)、VRF虚拟化路由表，用于路径隔离。

(3)、GRE Tunnel。

(4)、使用一些Overlay network封装协议并结合一操作系统虚似化实现网络分离。

Leaf-Spine网络架构解决了传统三层网络架构所面临的Oversubscription和内部服务器之间横截面带宽问题。Leaf-Spine网络架构在过去几年里已开始接管主要的云服务数据中心。Leaf-Spine结构也称为Clos结构，其中每个Leaf交换机（ToR交换机）以全网状拓扑连接到每个Spine交换机。这是一种两层的Fat-tree网络。这种架构中Leaf之间只有一个跳，最大限度地减少了任何延迟和瓶颈。Spine网络的扩展非常简单，只要在需增长的情况下逐步添加Spine交换机。

Leaf-Spine架构使用定制的寻址方案和路由算法，而非传统的STP。根据网络交换机中可用的功能，可以使用第2层或第3层技术实现Leaf-Spine网格。第3层的Leaf-Spine要求每个链路都被路由，并且通常使用开放最短路径优先（OSPF）或等价多路径路由（ ECMP ）来实现的边界网关协议（BGP）动态路由。第2层采用loop-free的以太网fabric技术，例如多链接透明互联（TRILL）或最短路径桥接（SPB, IEEE 8021aq）。其中，思科的FabricPath 和Brocade的Virtual Cluster Switching是基于TRILL发展而来的私有data plane。核心网络还可使用带有ECMP的动态路由协议通过第3层连接到主干网。华为、联想、Brocade、HP、 Extreme Networks等公司都有基于TRILL的产品或其它Leaf-Spine架构的解决方案。

Leaf-Spine结构的优点是：

(1)、使用所有链路互连，而不像传统网络中冗余链路被STP阻塞。

(2)、所有内部Leaf之间横向通信都是等距的，因此数据流延时时间是确定的。

(3)、Underlay的交换机配置和核心网络配置是固定的，因此变更Overlay Network的路由不需要更改核心网络。

(4)、产品安全区域能虚拟分离，扩展了VLAN和多租户安全性。

(5)、基础设施的物理网络可以和逻辑网络(Overlay network)分离。

Leaf-Spine结构也有些缺点，比如：

(1)、网络交换机的数量远远大于三层网络架构。

(2)、扩展新的Leaf时需要大量的线缆、并占用大量Spine交换机端口。

(3)、Spine交换机端口数量决定了最大可联接的Leaf交换机数量，也就决定了最大主机总数量。

下图是我参与过的一个公有云Leaf-Spine方案示意草图。

现代的数据中心部署中，我们一般将网络设备、服务器和机架在出厂时应模块化。对于使用Leaf-Spine 网络的数据中心，出厂时预装配成四种类型的标准工程系统：Transit 机柜, Spine 机柜, Fabric 机柜, 和 Server 机柜。Leaf 交换机和服务器一样被预装配于 Server 机柜，基本上做到开柜上电即可上线使用。

当下全球主流公有云基本上采用的都是Leaf-Spine 网络架构。然而，各家公有云服务商Leaf-Spine网络中的Underlay Network和Overlay Network使用的协议和方案有很大区别。比如，你可以基于Leaf-Spine架构使用VXLAN来设计你的SDN解决方案，也可以基于ECMP的BGP-labeled-unicast的underlay 网络，使用MPLS L3***s构建另一种多租户的数据中心SDN解决方案。

聊完了两种层数据中心网络架构，相信大家如有机会搭建新的网络时，应该知道如何选择您的网络架构方案了。

欢迎大家发表留言，谈谈你所熟悉的Leaf-Spine网络架构方案中，Underlay Network和Overlay Network使用的协议分别是什么。

参考资料：

(1)、 Building Multi tenant Data Centers with MPLS L3***s

(2)、 Cisco Data Center Spine-and-Leaf Architecture: Design Overview White Paper

不唯一，有spigot端，fabric端，Purpur端等多种选择。＜/strong＞＜br＞推荐用Purpur端，高度优化，同时可以在选项中开启刷沙，和各种dupe，比如tnt复制，也有一些其他的特性可以轻松自定义。＜br＞生电服即生存红石电路服务器，其玩法核心更偏向生存中的建筑与红石，本质上是共产主义，属于绝对纯净服和生存服。既然本质是共产主义，其对玩家要求就相当高，需要玩家拥有一定素质，服主需要设定白名单与黑名单。其核心的不同也会和一般生存服不同。

看起来似乎有强行把芯片设计和数据中心建设拉到一起尬聊的感觉，但世间也没有那么多的一见如故，一些有意义的讨论未尝不是从尬聊开始的。

就我个人而言，今年已经多次在关于数据中心的文章和（线上）分享中提到AMD：“从1月29日开始到2月6日，腾讯会议每天都在进行资源扩容，日均扩容云主机接近15万台，8天总共扩容超过10万台云主机，共涉及超百万核的计算资源投入，全部由腾讯云自研的服务器星星海提供支撑。”这款服务器基于AMD去年8月发布的代号Rome（罗马）的第二代EPYC处理器，最大的特点就是核多——双路配置再算上超线程，一台采用腾讯云定制版EPYC处理器的星星海服务器可以为云服务器提供多达180个核——也就是说，这100万核服务器资源，“只”需要不到6000台该款自研服务器即可满足。

腾讯云星星海SA2服务器采用2U高度结合类似远程散热片（remote heat-sink）的设计，配合6个60mm风扇，据称可以支持2个300W级别的CPU（AMD第二代EPYC处理器公开版本最高TDP为280W）

实际上，官方名称为AMD EPYC 7002系列的第二代EPYC处理器最多能提供64个核芯、128个线程，腾讯云定制版本选择了48核芯（96线程）而已。至少在CPU的核数（core count）上，AMD给Intel（英特尔，昵称“大英”）造成了很大的压力。上个月英特尔发布了代号为Cooper Lake的第三代至强可扩展处理器（Xeon Scalable Processor，XSP），主打四路和八路市场，四路配置可提供112核芯224线程，核数上堪与双路EPYC 7002系列抗衡，为10nm制程的Ice Lake争取时间。

摩尔定律难以延续的后果就是CPU的功耗持续攀升，第一代至强可扩展处理器（公开版）里TDP最高的205W，到第三代已是寻常，250W算是克制——毕竟要考虑四路的散热需求

话说上一次AMD搞得大英如此狼狈，还要追溯到本世纪初的64位路线之争。众所周知，英特尔是x86及其生态（特别是软件生态）的缔造者，属于“亲妈”级别，AMD充其量是个“后妈”。但是，x86几十年的发展史证明，“亲妈”未必就比“后妈”更了解孩子的发展潜力。也可以前一阵大火的剧集《隐秘的角落》为例，看完就会发现，对于朱朝阳的隐藏能力，后妈的认知似乎先于亲妈。

Cooper Lake：你看我还有机会吗？

简单的说，Intel建立发展x86生态，AMD坚定捍卫x86路线——不断改造作为生态核心的x86处理器，焕颜新生

盛衰无常：架构与制程的双簧

虽然已经在过去十年中逐渐沦为爱好者口中的“牙膏厂”，但在历史上，英特尔一直不乏创新精神。对待x86的态度可以算是这种精神的一个体现，起码在进入64位时代之前，英特尔其实不太瞧得上x86，总觉得这个娃太low——可能是亲妈更了解孕育过程中的种种先天不足吧——几次三番地在重大的转折点，想要“与时俱进”，重起炉灶，带给用户“船新体验”。反而是AMD屡屡在关键时刻出来捍卫x86，通过翻新加盖来维持其生命力。

64位是关键的转折点。上世纪九十年代末，还是32位的x86刚“插足”服务器市场不久，英特尔选择与惠普（HP）联手开发基于IA-64架构的Itanium（安腾）作为接班人，与已经64位了的RISC阵营大佬们对抗。然而，AMD认为x86还可以抢救一下，决定通过64位扩展来“续命”，并在2003年4月发布首款64位x86处理器Opteron，两年后又把x86(-64)带入多核时代。

此时，英特尔已经在IA-64的路上走了十多年。时过境迁，当初设定的目标并没有实现，而x86扩展到64位和多核之后，不仅软件和应用的生态系统得到了完整的继承，性能也完全可以一战。用户用脚投票，大英不得不从。

第二代EPYC处理器发布会上，Google出示2008年7月9日上线的其第100万台服务器的照片，追诉与AMD的革命友情……还是台四路服务器

英特尔痛定思痛，决定用架构和制程构筑双保险，在2007年提出了Tick-Tock（取自于时钟的“嘀-嗒”周期）量产模式，即先通过制程升级将芯片面积缩小，是为Tick；再基于操练纯熟的制程改用新的微架构，是为Tock。当时的英特尔工厂在技术和产能上都占据明显优势，只要架构上回到正轨，左右手组合拳一出，产量受限的AMD哪里支撑得住？在2008年推出Nehalem微架构之后，英特尔终于夺回主动权。

在英特尔施加的强大压力下，AMD在处理器架构上也犯了错误，2011年推出的Bulldozer（推土机）架构采用了即使现在看来也过于激进的模块化设计。随着2012年英特尔开启至强E5时代，AMD在节节失利后不得不退出服务器市场，上一个巅峰期彻底结束。

有道是：福兮祸所依，祸兮福所伏。先贤曾经曰过：纵有架构、制程双保险，奈何CEO是单点。2016年英特尔推出最后一代至强E5/E7（v4），这是英特尔首批采用14nm制程的服务器CPU，同时也宣告了Tick-Tock模式的终结，改用Process–Architecture–Optimization （制程-架构-优化）的三步走模式。

在这个可以简称为PAO的模式里，虽然仍是先制程、后架构的节奏，但新加入的优化不管是针对两者中的哪一个还是兼而有之，都起到了拉长制程换代周期的效果。第三代至强可扩展处理器已经是第四波采用14nm制程的服务器CPU，14nm后面的“+”都数不清楚有几个了——还好预计年底发布的Ice Lake将终止这个“土拨鼠之日”式的制程循环。

架构层面上，从代号Skylake的初代至强可扩展处理器开始，由环形总线改为6×6的2D-mesh，然后持续“优化”。在架构的角度，Mesh和环形总线都属于所谓传统的单片（Monolithic）式架构，优点是整体性好，涉及到I/O的性能比较有保证；缺点是对制程不太友好，随着规模的扩大，譬如核数和Cache的增加，良率上的挑战很大，高端产品的成本下不来，这对于追求高核数的云计算服务提供商显然不是个好消息。

至强E5/E7 v4的四环（2组双向环形总线）与至强SP的6×6 Mesh架构

关键时刻，又是沉寂多年的AMD挺身而出，接盘Tick-Tock，以自己的方式“维护”摩尔定律。

这个方式，就是模块化。

MCM：同构对等模块化的利与弊

先简单回顾一下AMD之前的模块化设计为什么会失败。 Bulldozer架构的模块化设计，建立在AMD对未来应用趋势的不靠谱假设上，即整数（Integer，INT）运算将占据绝对主导地位，结论是增加整数运算单元，减少浮点（Floating Point，FP）运算单元。 于是，Bulldozer架构很“鸡贼”的采用了两个（具有完整整数运算单元的）核芯共用一个浮点运算单元的模块化设计，两个模块就可以提供4个核芯（但只有2个浮点运算单元），6核以此类推。

模块化本身并没有错，Intel Nehalem的模块化设计就很成功。Bulldozer错在“拆东墙补西墙”，结果连补强都算不上

不用放马后炮，这也是一个妄揣用意（用户意志）的行为。即使是在AI大行其道的今天，第二代英特尔至强可扩展处理器已经支持INT8加速推理运算，也不能和通常意义上CPU的整数运算划等号。贸然押宝，错了当然怪不得别人。

不难看出，Bulldozer的模块化，与之前Intel Nehalem架构的模块化设计，只限于架构层面，并不是为制程考虑——CPU不论几个模块多少核，都是作为一个整体（die）来制造的，毕竟十年前制程还没到瓶颈。

然而，到了AMD以代号Naples的（第一代）EPYC处理器重返服务器市场的2017年，摩尔定律放缓的迹象已很明显。同样的14nm（可能还没有英特尔的先进）制程，AMD如何以更低的成本提供更多的核芯？

EPYC系列处理器基于AMD的Zen系列架构，从Zen、Zen+到Zen 2，以及规划中的Zen 3的发展路线，有点像前面提到的Tick-Tock：开发一个良好的基础然后交替演进，不断优化。

与先辈们不同，Zen系列的模块化明显侧重于解决制程面对的挑战，即芯片在物理上被切割为多个die（比较小的芯片更容易制造，良率有保证，有利于降低成本），通过Infinity Fabric（IF）互连为一个整体，所以每个die就是一个模块，但不一定是模块化设计的最小单位。

第一代EPYC处理器的4个die及Infinity Fabric示意

还是从初代EPYC处理器所采用的Zen架构说起。Zen确立了该系列计算单元模块化的最小单位CCX（Core Complex，核芯复合体），每个CCX包括4个Zen核芯（Core），以及8 MiB共享L3 Cache，每核芯2 MiB。

从AMD公开的示意图来看，各片（Slice）L3 Cache之间的连接方式像是full-mesh（全网状，即每两个点之间都有直接连接，无需跳转），CCX内部的跨核芯L3 Cache访问是一致的

Zen的CCD里除了2个CCX，还有2个DDR内存控制器（各对应1个内存通道），用于片上（die之间）互连的Infinity Fabric（IF On-Package，IFOP），而CPU之间互连的Infinity Fabric（IF Inter-Socket，IFIS）与对外的PCIe通道是复用的——这个知识点在后面会用到。

芯片层面的模块是CCD（Core Complex Die），包括2个CCX，共8个Core、4 MiB L2 Cache、16 MiB L3 Cache。官方名称为AMD EPYC 7001系列的第一代EPYC处理器只有CCD这一种（die层面的）模块，所以每个CCD除了2个CCX，还有大量I/O接口器件，包括DDR、Infinity Fabric/PCIe控制器，CCX占CCD面积的比例只比一半略多（56%）。

这个多芯片模块（multi-chip module，MCM）架构的代号为Zeppelin（齐柏林），四个这样的“复合型”CCD构成完整的第一代EPYC处理器，最多能提供32核芯、64 MiB L3 Cache，直接减少CCD的数量就会得到面向PC市场的高端（2×CCD）和主流产品（单CCD）。

按照AMD提供的数据：每个die的面积为213mm²（平方毫米），4个die的MCM封装总面积为852mm²，如果要用大型单一芯片来实现，面积可以缩小到777mm²，大约节省10%，但是制造和测试成本要提高约40%，完全32核的收益下降约17%、成本提高约70%。投入产出比当然非常划算，也变相的说出了大英的苦衷——可是，后者为什么还在坚持单片路线呢？

MCM这种完全对称的模块化方案，如果套用到数据中心领域，相当于一个园区，几栋建筑结构和功能完全一样，都包含了机房、变配电、柴发、冷站、办公和接待区域等。好处当然是彼此之间没有硬性依赖，每栋建筑都可以独立作为数据中心使用，照此复制就可成倍扩大规模；缺点是没有其他类型的建筑，而有些功能还是需要专门的建筑集中和分区管理的，譬如人员办公和统一接待……

如果一个数据中心园区只有黄框里这一种建筑（模块）……实际上，加上左边的66KV变电站，这里也只是整个园区的一角

况且，与绝大多数的数据中心园区不同，CPU对各模块之间的耦合度要求高得多，否则无法作为一个整体来运作，分工合作快速完成数据处理等任务。而这，正是MCM方案的局限性所在。

第一代EPYC的每个CCD都有“自己的”内存和I/O（主要是PCIe）通道，加上CCD之间的互连，每个CCD的外部I/O都很“重度”

多芯片（对称）设计、全“分布式”架构的特点是内存和I/O扩展能力与CCD数量同步，随着核芯数量的增加，内存和I/O的总“容量”（包括带宽）会增加，这当然是优点，但缺点也随之而来：

首先是局部性（locality）会降低I/O的性能，主要是跨CCD的内存访问时延（latency）明显上升。因为每组（2个）CCX都有自己的本地内存，如果要访问其他CCD上连接的内存，要额外花费很多时间，即所谓的NUMA（Non-Uniform Memory Access，非一致性内存访问）。虽然Zen的CCD上有足够多的IFOP，让4个CCD之间能组成全连接（full-mesh），无需经其他CCD跳转（类似于CCX内4个核芯之间的状况），但I/O路径毕竟变长了；如果要访问其他CPU（插槽）连接的内存，还要经过IFIS，时延会进一步上升。

CCD里的两个CCX也通过Infinity Fabric连接，同样会增加跨CCX的Cache访问时延

根据AMD提供的数据，不同内存访问的时延水平大致如下：

随着访问路径变长和复杂，时延以大约一半的比例增加，这个幅度还是很明显的。

同一个CCD里的内存访问没有明显差异，而跨CCD的内存访问，时延增加就很明显了

然后是PCIe，前面已经有图说明，Zen用于CPU之间互连的IFIS与PCIe通道是复用的，即单路（单CPU）的情况下全都用于PCIe通道，共有128个；双路（双CPU）的情况下每个CPU都要拿出一半来作为（两者之间的）IFIS，所以（对外的）PCIe通道数量仍然是128个，没有随着CPU数量的增加而增长。

简单归纳一下，Zen架构的问题是：核数越多，内存访问的一致性越差；CPU数量增加，外部I/O的扩展能力不变——NUMA引发的跨CPU访问时延增长问题还更严重。

单CPU就能提供128个PCIe 30通道原本是第一代EPYC处理器的一大优势，但双CPU仍然是这么多，就略显尴尬了

核数进一步增加的困难很大，不论是增加每个CCD的核数，还是增加CCD的数量，都要面临互连的复杂度问题，也会进一步恶化一致性。

说得更直白一些，就是Zen架构的扩展能力比较有限，难以支持更大的规模。

既然双路配置有利有弊，AMD又是时隔多年重返服务器市场，单路一度被认为是EPYC的突破口，譬如戴尔（Dell）在2018年初推出三款基于第一代EPYC的PowerEdge服务器，其中就有两款是单路。

1U的R6415和2U的R7415都是单路服务器

类似的情况在通常用不到那么多核及I/O扩展能力的PC市场体现得更为明显，在只需要一到两个CCD即可的情况下，消费者更多感受到的是低成本带来的高性价比，所以“AMD Yes!”的鼓噪主要来自个人用户，服务器市场在等待EPYC的进一步成熟。

只有1个die的Ryzen将Zen架构的缺点最小化，获得个人用户的喜爱也就不足为奇了

Chiplet：异构混合模块化的是与非

时隔两年之后，AMD推出基于Zen 2架构的第二代EPYC处理器，通过架构与制程一体优化，达到最高64核、256 MiB L3 Cache，分别是第一代EPYC的2倍和4倍，内存访问一致性和双路的扩展性也有不同程度的改善，终于获得了一众云服务提供商（CSP）的青睐。

Zen 2的整体设计思维是Zen的延续，但做了很多明显的改进，配合制程（部分）升级到7nm，突破了Zen和Zen+在规模扩展上的限制。

首先，Zen2架构延续了Zen/Zen+架构每个CCD有2个CCX、每个CCX有4个核芯共享L3 Cache的布局，但是每个核芯的L3 Cache增大一倍，来到4MiB，每个CCX有16 MiB L3 Cache，是Zen/Zen+架构的两倍。

CCD层面的主要变化是把DDR内存、对外的Infinity Fabric（IFOP/IFIS）和PCIe控制器等I/O器件剥离，以便于升级到7nm制程。AMD表示，第一代EPYC中，上述I/O器件占CCD芯片面积的比例达到44%，从制程提高到7nm中获益很小；而第二代EPYC的7nm CCD中，CPU和L3 Cache这些核心计算、存储器件的占比，高达86%，具有很好的经济性。

被从CCD中拿出来的DDR内存控制器、Infinity Fabric和PCIe控制器等I/O器件，组成了一个单独的I/O芯片，即I/O Die，简称IOD，仍然采用成熟的14nm工艺。

自左至右，分别是传统单片式、第一代EPYC的MCM、第二代EPYC的Chiplet三种架构的示意图

一个IOD居中，最多8个CCD围绕着它，AMD把这种做法称为Chiplet（小芯片）。

如果继续拿数据中心的模块化来强行类比，相当于把整个园区内的变电站、柴发、冷站、办公和接待区域都整合到一个建筑里，位于园区中央，周围是构造完全相同的一座座机房楼……你说，这样一个所有机房楼都离不开的建筑，该有多重要？

仅从布局看，和第二代EPYC处理器有点像的数据中心，但变电站在园区外，制冷也是分布式的（与4个机房模块在一起），中间的建筑并没有上面设想的那么重要

第一代EPYC处理器（Naples）与第二代EPYC处理器（Rome）的片上布局对比，后者是1个IOD + 8个CCD，共9个小芯片组成的混合多die设计

因为CCD的数量增加一倍，所以Rome的核数可以达到Naples的两倍；因为每个CCX/CPU核芯的L3 Cache容量也增加了一倍，所以Rome的L3 Cache总容量可以达到Naples的四倍。

14nm IOD + 7nm CCD的组合——因为不是全部升级到7nm，所以我更愿意称之为制程的“优化”——体现了更高的扩展性和灵活性，使第二代EPYC能够以较低的制造成本提供更丰富的产品组合，提高了市场竞争力。但是，事情并没有看起来这么简单，要了解产品的具体构成和预期的性能表现，您还需要继续往下看。

2019年8月，第二代EPYC正式发布后不久，AMD在Hot Chips大会上介绍了Zen 2产品的Chiplet设计。可能是之前有Zen+架构采用12nm制程的缘故吧，IOD的制程被写成了12nm，其他场合的官方材料都是14nm，所以我们还是以后者为准

今年2月IEEE的ISSCC（International Solid-State Circuits Conference，国际固态电路峰会）2020上，AMD更详细的介绍了Zen 2这一代产品的设计。结合前一幅图可以看到，第二代EPYC的IOD具有834亿晶体管，数量与同样采用14nm制程的英特尔Skylake/Cascade Lake相当——虽然两者的晶体管类型构成有很大差别，但可以作为一个参照，说明这个IOD自身的规模和复杂度。

从红框中的选项来看，EPYC 7302 CPU有4个CCD，每个CCX有2个核芯，可以选择各启用1个

IOD集中所有I/O器件的一个好处是，CPU能提供的内存通道数量与CCD的数量无关。E企实验室前一阵测试了基于第二代EPYC处理器的Dell PowerEdge R7525服务器，送测配置包括2个AMD EPYC 7302处理器，从PowerEdge R7525的BIOS设置中可以看到，这款16核的CPU有4个CCD（而不是8个），应该对应下图中右二的情形：

上方柱状图是AMD列出7+14nm Chiplet方案与假设的单片7nm方案相比，成本优势可以达到一半以上（64核没有假设，可能是指单片式很难制造）；下方从左至右依次是8、6、4、2个CCD的布局，原则是尽可能的对称

虽然7302在EPYC 7002系列产品中定位偏低端，只有16个核芯，用4个CCX就能满足，但是它拥有128MiB的L3 Cache，这又需要8个CCX才可以。因此，7302的每个CCX只有2个核芯，享受原本属于4个核芯的16 MiB L3 Cache。

从EPYC 7002系列的配置表中可以看出，7302下面72开头的产品才是真正的低端，譬如同样是16核的7282，不仅L3 Cache容量只有7302的一半（倒是符合每核4 MiB的“标配”），而且仅支持4个内存通道，也是7302等产品的一半——说明其CCD数量是2个，就像前一幅图右下方所示的情况——4个内存通道配置的运行频率也低，只有DDR4-2667，与标准的8通道DDR4-3200相比，理论内存带宽仅为40%多

Dell PowerEdge R7525用户手册里对内存条的安装位置有很详细的说明，毕竟插满8个内存通道和只用4个内存通道，性能差距太大

IOD集中所有I/O对性能也有好处，因为内存控制器集中在一个芯片上，有助于降低内存访问的局部性（NUMA）。不过，AMD在很多场合放出的示意图很有误导性，容易让人以为，对Rome（下图右侧）来说，同一个CPU上的内存访问是不存在NUMA的。

从上面的数据来看，第二代EPYC处理器的“本地”内存访问时延有所增长，毕竟内存控制器和CCX不在一个die上了；收益是跨CPU内存访问的时延有所下降，总体更为平均

好在，稍微详细一点的架构示意图表明，一个EPYC 7002系列CPU内部的内存访问仍然会有“远近”之分：

Dell PowerEdge R7525的BIOS配置中，可以在L3 Cache的NUMA设置为Enabled之后，看到每个CPU内部其实还是可以像EPYC 7001系列一样，分成4个不同的NUMA区域

这时学术性会议的价值就体现出来。AMD在ISSCC 2020上的演讲表明，完整版的Server IOD要承载的功能太多，已经有太多的晶体管，中间都被Infinity Fabric和PCIe相关的I/O所占据，内存控制器只能两两一组布置在IOD的四角，每2个CCD就近共享2个内存控制器。由于中间已经没有走线空间，只能构成一个没有对角线连接的2D-mesh拓扑——仅从拓扑角度而论，还不如EPYC 7001系列4个CCD的full-mesh连接方式。所以，临近的访问有长短边造成的延迟差异，对角线的内存访问因为要走过一长一短两条边，没有捷径可走，自然要更慢一些。

注意放大看IOD布局示意图和右侧1～4的不同等级时延注解，可以理解为每个CPU内部仍然分为4个NUMA区域：本地、短边、长边、（拐个弯才能抵达的）对角线

Hot Chips大会上的这张示意图突出了不同功能的Infinity Fabric导致的IOD中部拥挤，和DDR内存控制器都被挤到边角上的感觉。结合前一张图，不难理解，像EPYC 7282这样只有2个CCD对角线布置的低端SKU，另一条对角线上的4个DDR内存控制器主要起增加内存容量的作用，不如只保留CCD就近的4个内存通道

总之，不管是EPYC 7001系列的MCM，还是EPYC 7002系列的Chiplet，随着芯片数量的增长，性能肯定会受到越来越明显的影响（而不是近乎线性的同步提升），只是好的架构会延缓总体性能增长的衰减速度。

这里我们可以回过头来看看同样基于Zen 2架构的第三代AMD Ryzen处理器，主流PC产品没有那么多核数要求，只用2个CCD即可满足，所以其配套的Client IOD（cIOD）正好是Server IOD的四分之一，从前面图中晶体管数量的对比（209亿 vs 834亿）也可以看出来。

代号“Matisse”的第三代Ryzen，仍然可以看到两个DDR4内存控制器偏居一隅的“遗存”，但对两个CCD已经公平了很多，基本不存在NUMA问题。也就难怪“AMD真香”党在消费类用户中比例要大得多

尽管CCD升级到了7nm，但更多核芯、更大得多的L3 Cache，意味着整体功耗的上升，譬如同样16核的7302和7282，前者Cache大一倍，频率略有提高，默认TDP就来到了155W，Dell为送测的R7525配备了180W的散热器——而EPYC 7282的TDP则“只有”120/150W。当然，CCD应用7nm的效果还是比较明显的，同样16核、L3 Cache只有7302四分之一，运行频率还低500MHz的7301，TDP也有150/170W，基本与7302相当。

为了满足云计算、高性能计算（HPC）和虚拟化等场景的用户需求，AMD又向EPYC 7002系列CPU中增加了大量多核大(L3) Cache以及核数虽少但频率很高的型号（如今年初发布的7Fx2系列），导致全系列产品中TDP在200W以上的SKU占比很高，也给服务器的散热设计带来了更高的挑战。

200W+的CPU将越来越常见

EPYC 7002系列的另一大改进是PCIe从30升级到40，单路仍然是128个通道，但双路可以支持多达160个通道（譬如Dell PowerEdge R7525的特定配置）——在主板支持的情况下。第一代EPYC处理器推出时的一个卖点是，为其设计的主板也可以支持第二代EPYC处理器。没有广而告之的是，要支持PCIe 40，主板需要重新设计。用老主板可以更快的把第二代EPYC处理器推向市场，却不能充分发挥新CPU的全部能力。

不过，PCIe 40本身就是一个很大的话题，留待以后（有机会的话）专文讨论。

平台运维岗位职责15篇

　随着社会不断地进步，岗位职责的使用频率呈上升趋势，制定岗位职责可以有效地防止因职务重叠而发生的工作扯皮现象。那么什么样的岗位职责才是有效的呢？下面是我帮大家整理的平台运维岗位职责，仅供参考，大家一起来看看吧。

平台运维岗位职责1

　1、熟悉云技术架构，OpenStack，docker技术等

　2、熟悉Unix，linux，windows操作系统，虚拟化平台运维，熟悉脚本开发语言，

　3、熟悉IaaS层云计算与虚拟化概念、有云主机、云存储相关实施经验

　4、熟悉主流云计算产品，对相关云产品有运维经验优先

平台运维岗位职责2

　 岗位职责：

　1虚拟化、网络存储、服务器、数据中心、大数据、相关产品的项目交付或支撑项目迁移上云;

　2与客户有效沟通技术方案、项目计划和进度等，获得客户支持和认可;

　3正确理解、有效分析和管理客户需求;

　4初步掌握项目管理基本方法和工具，并运用到工作中，具备项目技术管理成功实践;

　 任职资格：

　1本科学历，学信网可查，计算机软件相关专业，具有三年以上相关云计算工作经验，熟悉操作系统、网络存储、数据库等，熟悉国内主流公有云服务商应用;

　2熟悉虚拟化技术(KVM/Xen/LXC等)，了解OpenStack,CloudStack等云计算开源平台，了解Nginx,Nagois,Zabbix,OVS,CEPH等相关开源技术;

　3熟悉路由器、防火墙、交换机、负载均衡等网络设备的配置;

　4、具有良好的技术前瞻性，独立的技术分析及故障处理能力，性格开朗，具有合作精神，良好的服务意识，责任心强;

　5、良好的沟通和交流能力，强烈的学习欲望。

　6具有华为云平台实施和维护经验(VM，思杰，cytrix)，或具有华为存储产品认证者(HCNP，HCIE)优先

平台运维岗位职责3

　 职责：

　1业务平台的日常管理和维护。

　2服务器的配置、维护、监控、调优，相关故障、疑难问题排查处理。

　3应用系统性能优化。

　4保障服务器与业务平台安全，检查并消除安全漏洞。

　5设计业务平台和服务器可靠性保障方案、升级方案。

　 任职要求：

　1 3年以上在线系统运维工作经验，精通Linux系统及常见服务的安装配置，熟悉常见的负载均衡实现方案并有实际实施经验。

　2精通Apache、NginX、MySQL等常用服务的安装、配置和维护。

　3精通和灵活运用一种以上的脚本语言，包括但不限于：Shell、Python等。

　4能够熟练排查运维过程中出现的服务故障、系统故障、网络故障。

　5高度的责任感，较强的故障分析及排除能力，善于在工作中学习，能够承受工作压力，能适应短期出差和加班。

　6优先考虑：精通LAMP架构，熟悉PHP，有相关大中型在线系统开发及维护经验。

平台运维岗位职责4

　 系统平台运维经验要求:

　1具备aix、linux、windows操作系统的实际操作能力及日常运维能力(安装、监控、升级、lvm管理等),熟悉常用配置文件修改;

　2熟悉das、nas、san、存储虚拟化的构架和原理。

　3熟悉dell/emc、hds、netapp、华为等品牌的主流存储产品,能够进行配置调整,并独立完成故障诊断、备件更换等工作;

　4具备存储级别的容灾、数据迁移项目实施经验优先;

　5熟悉shell脚本,并有一定编写脚本能力。

　6熟悉vmware、hyper-v等虚拟化平台架构,对vmware的存储、灾备、网络、安全、升级、虚拟机管理、监控和性能等有深刻的理解。具备常见故障的分析和判断能力,熟悉vmware vsan架构者优先,具备vcp资质优先。

　7了解企业级备份系统构架,对于涉及虚拟机及存储各种备份技术及应用能熟练应用。

　8有一定的学习能力、抗压能力、解决问题能力、研究精神。

　 其他要求:

　1、热爱岗位、勤学肯干,

　2、能够接受日常加班、能够在一定压力下工作

　3、具有团队协作精神

　4、工作稳定性

　 工作职责:

　1负责服务器和存储操作系统及基本应用的配置、安装、管理及维护;

　2负责服务器、存储设备运行状态进行监控与巡检;

　3负责对服务器、存储设备的性能进行分析与优化;

　4负责协调供应及二线人员对突发事件的应急处理;

　5负责执行服务器、存储、虚拟化相关变更及发布;

　6协助进行数据库、中间件相关运维工作;协助开展信息安全工作运维工作。

　7负责组织配合二线支持人员进行现场支持工作

平台运维岗位职责5

　1了解市场及用户需求，负责公司云产品规划、方案设计、运营及资源管理;

　2负责面向研发中心的云产品需求对接，提供云产品开发方向设计。

　3负责面向云服务商的技术交流，优化提升公司云产品、保障公司云产品的正常运营;

　4解决用户在使用公司云产品及其应用过程中的各种问题并做好记录;

　5负责运营数据的统计与分析，并定期提交分析报告。

平台运维岗位职责6

　职责：

　1、负责公司海外游戏运营平台基础应用架构设计、部署、性能调优以及维护。

　2、负责公司大数据平台应用环境的架构设计、部署、性能调优以及维护。

　3、协助开发部进行平台代码配置管理的规划、流程和策略的制定，严格执行代码的版本管理、发布管理、变更管理和配置审计。

　4、负责公司企业邮箱系统的日常运维管理

　任职要求：

　1、本科以上学历，三年以上互联网平台从业经验，有游戏行业从业经验优先考虑。

　2、精通Centos/Ubuntu等Linux操作系统，对系统性能安全优化有深入理解。

　3、精通Lvs/Haproxy+Keepalived+Nginx/openresty+Resin/Tomcat+Redis/Mongodb/Memcache+Mysql的配置、使用以及调优，有丰富的DBA工作经验。

　4、熟悉git版本控制工具的使用。

　5、熟悉Jenkins持续集成工具的使用，对maven的构建过程与原理有所了解。

　6、熟悉Elk+Zookeeper+Kafka分布式日志集群系统有比较深入的实际工作经验。

　7、熟悉Hadoop+Spark大数据开发框架，能给予大数据团队提供基础的大数据应用服务。

　8、熟悉postfix+extmail+SpamAssassin邮件系统的部署;熟悉常用的反垃圾邮件组件。

　9、具有shell或python语言开发能力，对自动化运维体系有比较深刻的理解，认同devops工作理念。

平台运维岗位职责7

　1、部署环境实施规划

　2、K8S部署安装

　3、GitLab，Nginx，Jenkins，Redis，Mysql，Harbor软件安装部署

　4、Spring cloud微服务部署

　5、远程访问软件安装

　6、服务器linux系统安装，KVM虚拟化

　7、大数据集群机器容量(CPU，内存，硬盘)以及组件规划

　8、售后技术支持

　9熟悉主流服务器调测配置

平台运维岗位职责8

　 云平台运维工程师杭州漠坦尼科技有限公司杭州漠坦尼科技有限公司,漠坦尼,漠坦尼职责描述:

　1、负责基于openstack的云平台部署、运维工作,参与openstack运维系统的研究工作;

　2、负责组织openstack技术研究和攻关工作;

　3、负责openstack运维工作;

　4、解决openstack云平台的故障。

　5、把握openstack技术发展的大方向,跟进社区及主要商业版本的技术演进路线;

　 任职要求:

　1、对openstack架构和各个模块有深入的理解,参与过架构设计及优化；

　2、了解sdn/nfv,熟练掌握ovs、openflow、vxlan等sdn技术,熟练掌握基本网络原理,可针对不同环境规划openstack网络;

　3、精通linux系统原理,tcp/ip通信原理,熟悉python,熟悉docker,

　4、熟悉iptables、ebtables等linux网络技术和常用网络通信协议;

　5、熟悉vmware、kvm、hyper-v等虚拟化技术；

平台运维岗位职责9

　Responsibility

　1、解决藏宝阁各种紧急事件，日常问题查证和BUG跟进处理，与产品及技术沟通协调问题处理方案;

　2、利用脚本完善运维处理工具，提交需求优化操作后台，提高运维以及一线工作人员工作效率;

　3、对运营数据进行分析，根据运营中出现的问题进行分析，及时输出分析报告及解决方案;

　4、对相关运营流程、活动流程进行梳理，并对一线客服人员进行培训和规范，提高日常问题及活动问题处理效率及用户满意度并对相关KPI负责。

　Requirements

　1、具有高度的保密意识和责任心，能承受较强的工作压力;

　2、积极主动，敢于接受挑战，性格开朗，有较强的团队合作精神，乐于分享;

　3、精通梦幻系列、大话系列等公司主流端手游游戏设置，对游戏有一定敏感性

　4、熟练Python使用，具有一定的数据分析能力;

　4、善于人际沟通，熟悉团队各类业务流程;

　5、熟练使用excel、word、PPT，了解internet网络知识。

平台运维岗位职责10

　职责：

　1、负责私有云PaaS平台平台整体功能规划及系统设计;

　2、负责私有云PaaS平台平台基础中间件及基础数据库服务的规划及系统设计;

　3、负责私有云PaaS平台平台微服务应用相关的服务规划及系统设计;

　4、负责公司已有IT系统私有云PaaS平台平台部署的架构和迁移方案设计，并对应用迁移到私有云PaaS平台上提供技术支持;

　5、指导并带领开发工程师进行详细设计、系统开发等工作，保障设计方案的实施与落地。

　职位要求

　1、本科及以上学历，计算机相关专业，5年以上工作经验，云计算相关工作经验2年以上。

　2、具备较强私有云平台开发能力，至少精通Java/Shell编程语言，至少拥有阿里云、私有云PaaS平台的设计开发经验，有完整私有云平台(IaaS+PaaS)产品搭建经验值优先;

　3、精通docker/Kubernetes容器技术，了解cgroup/Namespace技术原理;

　4、熟练OpenShift、Spring Cloud、Dubbo技术，有完整的微服务设计和相关使用规范;

　5、熟悉常用中间件(如Redis、RocketMQ、Kafka、ElasticSearch等)及分布式数据库的原理及集群构建，有实际项目经验者优先;

　6、熟悉分布式架构基本原理，包括分布式计算、分布式存储、分布式缓存、分布式数据库、分布式消息中间件等，在高性能计算、并行处理、Linux环境、虚拟化技术、集群部署、分布式任务调度、分布式资源管理等云计算相关领域有开发经验者优先;

　7、具有物联网，流媒体等PaaS产品设计开发经验者优先;

平台运维岗位职责11

　职责:

　1、配合对系统进行持续优化，满足高可用、高性能等特性;

　2、负责服务器配置管理、基础软件安装以及性能调优、应用部署等工作;

　3、配合解决运维工作中重大故障，性能瓶颈等相关疑难问题;

　4、配合优化运维规范、工作流程、应急预案等。

　任职要求：

　1、两年以上互联网运维经验，了解容量规划、性能优化;

　2、熟悉linux系统，了解tcp/ip以及具有丰富的广域网、局域网网络络知识;

　3、有网站运维经验，熟练使用shell脚本编程语言;

　4、熟悉MySql，Redis，Elasticsearch等;

　5、具有故障排查能力，有很好的技术敏感度;

　6、有自动化运维经验，熟悉Puppet、Saltstack、Ansible以及Fabric的优先;

　7、熟悉如Nagios、Cacti、zabbix、zenoss等监控监控软件并能对相关指标进行分析;

　8、有DBA经验的优先。

　平台架构师负责企业服务类Saas产品的架构设计和落地，其中包括但不限于存储、安全、中间件、网络、DevOps等各类云产品。下面我给大家带来关于平台架构师岗位职责，希望会对大家的工作与学习有所帮助。

平台运维岗位职责12

　 职责：

　1、负责已验收项目的运维工作(系统安装部署、使用问题咨询、升级维护等);

　2、负责已验收项目的问题及需求梳理，收集客户反馈的问题和新需求，整理成文档;

　3、负责已验收项目的系统维护，包括系统常见问题的处理，确保系统正常运行等;

　4、负责已验收项目的软件开发及优化，包括软件使用过程中出现的问题定位、分析、解决，负责软件Bug修复和新需求功能开发;

　5、负责已验收项目的软件相关文档编写及汇报相关工作。

　6、完成部门领导安排的其他日常事务。

　 任职要求：

　1、计算机等相关专业本科及以上学历;

　2、具备良好的沟通协调能力，文档编写能力;

　3、熟悉java，spring，hibernate，js，jquery，jsp，SQLServer，Oracle数据库等基础;

　4、有信息化系统运维开发经验，优先考虑。

　5、有环保行业工作背景优先。

平台运维岗位职责13

　职责：

　1、负责智慧城市平台领域的需求分析、产品与架构设计，编写核心代码;

　2、负责系统的安全性，高可用性，性能优化以及开放扩展性;

　3、制订和review产品领域的技术规范，指导和培训开发工程师;

　4、负责项目进度把控，线上故障的及时排错及处理;

　5、研究新的web、云计算、大数据平台和技术;

　6、参与技术研发团队管理工作;

　任职要求：

　1、5年以上Java研发和软件设计经验;

　2、2年以大型项目及平台设计经验，有大型互联网平台设计与研发经验优先;

　3、熟练掌握主流应用服务器架构体系，数据库以及各种中间件技术，如Tomcat、Redis、Memcahced、HTTP、Ajax、MySQL、JMS等;

　4、熟悉大规模系统的负载均衡、缓存、网络存储、网络安全、数据库高可用设计及性能评估机制;

　5、 具备良好的系统分析能力，良好的抽象思维和逻辑思维能力，独立分析问题解决问题的能力;

　6、可承受较大压力，有责任感，较强的沟通协调能力，具有团队合作精神,能带领团队进行主要平台产品的研发和平台升级优化;

　7、有团队管理经验，熟悉大型项目管理流程规范，有PMP等项目管理证书者优先;

平台运维岗位职责14

　职责：

　1 负责公司的新产品研发 ;

　2 深入发掘和分析业务需求，撰写技术方案和系统设计 ;

　3 核心代码编写、指导和培训工程师、不断进行系统优化

　岗位要求：

　1 JAVA基础扎实，理解io、多线程、集合等基础框架，对JVM原理有一定的了解;

　2 4年及以上使用JAVA开发的经验，对于你用过的开源框架，能了解到它的原理和机制;对Spring,Spring Boot等开源框架熟悉;

　3 熟悉分布式系统的设计和应用，熟悉分布式、缓存、消息等机制;能对分布式常用技术进行合理应用，解决问题;

　4 掌握多线程及高性能的设计与编码及性能调优;有音视频服务器开发经验;

　5 掌握Linux 操作系统和大型数据库(Postgresql、MySql、nosql);对sql优化有丰富的经验;

　6 学习能力强，适应能力好;具备耐心/细心的品质;

　7 喜欢去看及尝试最新的技术，追求编写优雅的代码，从技术趋势和思路上能影响技术团队。

　网站工程师需要负责网站的日常维护，保证网站的安全，维护相关的工具,是一个公司很重要的岗位。下面我给大家带来关于网站工程师工作职责，希望会对大家的工作与学习有所帮助。

平台运维岗位职责15

　 平台运维工程师：

　一、

　1、 cloudera大数据平台集群规划与搭建;

　2、大数据平台安全防护与应急响应;

　3、协助研发团队对存储资源以及集群资源统一分配与调度、性能调优、故障分析与诊断;

　4、实时监控接入平台的saas服务的所有数据安全等;

　5、按照安全架构师的统一规划实施数据平台等保三级相关配套防护措施;

　6、与cloudera等合作伙伴保持良好互动,协调iaas运维工程师解决数据

　二、

　1、 paas平台日常运行和维护;

　2、 paas资源安全防护与应急响应;

　3、协助研发团队对容器与容器镜像资源统一分配与调度、性能调优、故障分析与诊断;

　4、实时监控接入平台物联设备应用安全、数据安全和网络安全等;

　5、配合集团paas平台集群对接,保证上海paas平台高可用性;

　6、与paas合作伙伴保持良好互动,协调iaas运维工程师解决各种突发问题

;

因为压根不是你的问题。

关于显卡驱动还是去Intel官方或者你笔记本携带了电脑管家（要求笔记本厂商的）可以换一下。

Optifabric的Bug非常多甚至和Fabric冲突(这不奇怪，隔壁OptiFine和Forge冲突)。

建议使用钠模组等一众优化模组而不是Optifabric,Fabric也有对应的光影模组不必担心。

1、服务器编程：以前你如果使用C或者C++做的那些事情，用Go来做很合适，例如处理日志、数据打包、虚拟机处理、文件系统等。

2、分布式系统、数据库代理器、中间件：例如Etcd。

3、网络编程：这一块目前应用最广，包括Web应用、API应用、下载应用，而且Go内置的net/http包基本上把我们平常用到的网络功能都实现了。

4、开发云平台：目前国外很多云平台在采用Go开发，我们所熟知的七牛云、华为云等等都有使用Go进行开发并且开源的成型的产品。

5、区块链：目前有一种说法，技术从业人员把Go语言称作为区块链行业的开发语言。如果大家学习区块链技术的话，就会发现现在有很多很多的区块链的系统和应用都是采用Go进行开发的，比如ehtereum是目前知名度最大的公链，再比如fabric是目前最知名的联盟链，两者都有go语言的版本，且go-ehtereum还是以太坊官方推荐的版本。

自10版发布以来，go语言引起了众多开发者的关注，并得到了广泛的应用。go语言简单、高效、并发的特点吸引了许多传统的语言开发人员，其数量也在不断增加。

使用 Go 语言开发的开源项目非常多。早期的 Go 语言开源项目只是通过 Go 语言与传统项目进行C语言库绑定实现，例如 Qt、Sqlite 等。

后期的很多项目都使用 Go 语言进行重新原生实现，这个过程相对于其他语言要简单一些，这也促成了大量使用 Go 语言原生开发项目的出现。