1.物理设备层面：1).服务器标签化（IP地址/与交换机接口/当前服务/）、设备负责人（管理人）、设备采购详情（保修日期）、设备摆放标准（服务器之间间隔1U通风）。2).网络划分、远程控制卡、网卡端口。3).服务器厂商机型号同一、硬盘大小转速同一、内存统型号大小频率一、服务器课根据业务分类，有的要求IO高（存储服务器），有的要求内存大（缓存服务器），有的要求CPU块（代理服务器），有的对CPU和IO要求CPU和内存都高（数据库服务器）。4).资产命名规范、编号规范、类型规范。5).监控标准（统一阈值和监控类型）。
2.操作系统层面：
3.应用服务层面：1).Web服务器选型（LNMP/LAMP/Tomcat/MySQL）2).进程启动用户身份及目录、端口监听规范、日志收集规范（访问日志、错误日志、运行日志、系统日志）3).配置管理（配置文件规范、脚本规范）4).架构规范（Nginx+Keepalived、LVS+Keepalived、Haproxy+Keepalived、阿里云SLB、UcloudULB等等）5).部署规范（位置、包命名等）
4.运维操作层面：
运维工具化带来的好处：1).促进标准化的实施2).将重复的操作，简单化3).将多次操作，流程化4).减少人为操作的低效和降低故障率
运维工具化遇到的问题：1).你至少要ssh到服务器执行。可能犯错2).多个脚本有执行顺序的时候，可能犯错。3).权限不好管理，日志没法统计。4).无法避免手工操作。例子：比如某天某台Web服务器磁盘可能发生问题，要在访问量较低的凌晨要将服务器的数据导出来放在其他服务器替代，那么需要考虑的是：1).是否有由其他服务器连接此服务器取数据或此服务器是否到其他服务器取数据。2).此服务器是否有定时任务计划到其他服务器执行或有其他服务器连接到此服务器执行。3).任务计划索要涉及的内容，以及停服务是否影响其他服务器。4).后续的代码更新问题。
六：自动化运维之服务化（API化）
1).DNSWeb管理———->bind-DLZdns-api（bind）2).负载均衡Web管理——>slb-api（haproxy、LVS、Nginx）3).Job管理平台————->job-api（php自主开发）4).监控平台Zabbix——->zabbix-api（zabbix、nagios、cacti）5).操作系统安装平台——>cobbler-api（cobbler、kickstack）6).部署平台——————>deploy-api（安装服务软件nginx+php）7).配置管理平台————>saltstack-api（saltstack、ansible）8).自动化测试平台———>test-api（自主开发测试）
自动化扩容机制：1).扩容之前：先判断Buffer区域是否有最近x小时，已经移除的之前创建的虚拟机，并查询软件版本是否和当前一致，如果一致，跳过234步骤，如果不一致，跳过23。2).OpenStack创建虚拟机3).Saltstack配置环境—-监控4).部署系统部署当前代码5).测试服务是否可用（注意间隔和次数）6).加入集群7).通知（短信、邮件）自动化缩容机制：1).触发条件和决策2).从集群中移除节点-关闭监控-移除3).通知4).移除的节点存放于Buffer里面。5).Buffer里面超过1天的虚拟机，自动关闭，存放于xx区6).Buffer区的虚拟机，每7天清理删除。
##################################################################################
自动化安装和部署概述
一、自动化安装1.采购–>验货–>签字，验货单，盖公章。
2.资产管理：资产录入–>机房、区域、排、机柜、位置、配置（资产管理，验收单）（自动化获取）
3.RAID-（验货的时候）RAID,自动化进行配置
4.CMDB：资产录入–>机房、区域、排、机柜、位置、配置。MAC地址清单。+（后期收集）资产收集、录入，管理和AP，并且展示。
5.开机关机重启（IPMI）
6.详细配置IP地址掩码网关主机名DNS（DNS解析）->开始安装–>使用cobbler
7、安装完毕。角色(APINginxPHP(memcacheredispdo)启动，代码部署)
8.SaltStack-salt-key执行状态，配置完毕。
9.自动进行检查（测试系统）+（etcd）加入集群。
10.加入监控
二、自动化部署
1、部署环境
开发环境
测试环境（功能测试、性能测试）
预生产环境即灰度环境（生产环境的一个不对外的节点，和生产环境公用一套数据库、redis等资源）
生产环境
2、代码部署的几种情况
第一种gitpullsvnupdate
rsync缺点：不能做到及时回滚，适合代码更新非常不频繁的情况
第二种rzsz缺点：毫无任何优点
3、实现真正的自动化部署
下文的前提是针对运维来说：代码已经在发布分支，进行发布。
1）获取代码gitpull
a、最新的b、commitidc、做好tag
2）编译（可选）build(antmaven)
3）配置文件。
a、分环境（配置单独进行存放，config.example）
b、统一的.集群有10个节点。Job节点crontab.xml
5）文件分发（SCPsalt-cprsync）校验md5
6）将待部署节点，从集群中摘除
7）解压软件包
8）创建软连接
软连接是关键是关键，速度快，准确。同时存在缺点，一定要重启php（清除opcache），tomcat等服务
9）同步差异配置文件
10）重启Web服务
11）测试，验证，如果不通过则停止升级
12）加入集群
3、自动化部署的优势
1.快速回滚
2.部署统计（使用nginx，禁止访问.svn）
3.配置文件管理
三、回退（回滚）1、紧急回退
1）列出版本
2）回退
2、正常回退
正常回退到上一个版本，此次bug影响面波及不大，不涉及钱财的订单交易，不建议使用紧急回退方式，
建议使用重新发布上一个的方式。
四、拓展并行：由于上述上线方案默认是串行方式，在这里可以可以分组部署，达到一个并行的效果，同时可以让测试人员分组测试，已满足上线要求。当然，这是node很多的情况，具体情况依照公司情况分析。
日志记录：日志当然是必要的，这里不再强调。
部署服务器双机：从携程的事情上，得到教训，双机部署的重要性，如果不是携程的人员及时在一个机器上找回了代码，后果就不堪设想啦。
回滚的必要性：这里提到了回滚的必要性，这是必须要执行的，遇到问题及时回滚，尤其是在业务高峰阶段，谨记不要上线代码！切记不能让开发人员在关键时刻修复bug，这样只会越拖越久，最终挨批的一定是运维人员。这是运维背黑锅的最大痛点之一，CEO绝不会把责任归属于开发，反而会问运维人员，为什么不执行回滚。
###############################################################################
自动化部署基础与shell脚本实现
关于自动化的基础知识：
1.1：当前代码部署的实现方式：
1.2：运行环境规划：开发环境：开发者本地有自己的环境，然后运维需要设置开发环境的公用服务，例如开发数据库、redis、memcached等测试环境：功能测试环境和性能测试环境预生产环境：由生产环境集群中的某一个节点担任测试，此节点只做测试不对外提供服务生产环境：直接对外提供服务的环境
为什么有预生产环境？可能是生产环境预测试环境的数据库或数据库版本不一样导致语句出现问题或者是生产环境调用的接口不一样，例如支付接口在测试环境无法调用
1.3:设计一套生产环境的代码自动化部署系统：
开发环境-->功能测试/性能测试-->预生产环境-->生产环境
1.4：总体规划流程：一个服务的集群节点数量，是一次部署还是分次部署一键回滚到上个版本一键回滚到任意版本代码保存在SVN还是Git获取指定分支或master的指定版本号的代码，svn指定版本号，git指定tag标签，或直接拉取某个分支配置文件差异化，即测试环境和生产环境的配置文件不一样，如IP不一样或主机名不一样或数据库连接不一样等等代码仓库和实际的差异，即配置文件是否放在代码仓库中，如果保存在git则所有人都可以从配置文件看到数据库用户密码等信息，可以使用单独分支保存配置文件，或配置文件只在部署服务器的某个项目的目录，比如是config.example如何更新代码，javatomcat需要重启测试部署后的web页面是否可以正常访问是否是想要的页面并行(saltstack)或并行(shell)的问题，涉及到分组部署重启服务如何执行，shell执行还是web执行
1.5：总体规划如下：
获取代码(gitpull拉取)-->是否编译(java需要编译)-->配置文件(统一和差异)-->打包-->scp到目标服务器(或者用saltstack)-->将服务器移除集群-->解压代码包-->放置到目标目录(如webroot)-->scp差异文件-->重启服务(可选)-->测试服务(访问web或者post请求)-->将节点重新加入集群
二：实现代码自动化部署
2.1:通过shell脚本实现，shell脚本规划如下：
2.1.1：各web服务器添加一个uid相同的普通用户，而且所有的web服务都以此普通用户启动，默认情况下所有的wenb服务除了负载均衡之外都不能监听80端口，比如可以监听8008端口
#useraddwww-u1010#su–www$ssh-keygen#将部署机www用户的公钥复制到各web服务器的/home/www/.ssh/authorized_keys或执行ssh-copy-idwww@192.168.3.13
$chmod600/home/www/.ssh/authorized_keys
2.2：编写shell脚本：2.2.1：完成框架编写：
2.2.2：完成脚本：实现代码部署、测试、回滚等操作：
代码回滚设计：正常回滚是回滚已经在web服务器部署过的版本，因此就不需要获取代码打包和部署的过程了
列出回滚版本将模板服务器移除集群执行回滚重启和测试将模板服务器加入集群
3.通过刚才编写的shell脚本将html官网页面部署到nginx中
①将代码上传到部署节点的/deploy/code/web-demo目录中
[www@masterweb-demo]$pwd/deploy/code/web-demo[www@masterweb-demo]$lltotal20drwxr-xr-x6wwwwww4096Jun613:46assets-rw-r--r--1wwwwww1150Jun617:59favicon.icodrwxr-xr-x2wwwwww4096Jun615:32images-rw-r--r--1wwwwww4323Jun616:19index.html
部署节点执行以下操作：
#mkdir-p/deploy/code/web-demo#mkdir-p/deploy/config/web-demo/base#mkdir-p/deploy/config/web-demo/other#mkdir/deploy/tmp#mkdir/deploy/tar#chown-Rwww.www/deploy#chown-Rwww.www/webroot#chown-Rwww.www/opt/webroot/
②需要在客户端做的操作#安装nginx#yuminstall-ynginx
编辑nginx
vim/etc/nginx/conf.d/cloudeye.confserver{listen9999;server_name192.168.3.13;#实际生产环境中需要填写域名location/{alias/webroot/web-demo/;#这个web-demo目录不需要创建，有软链接指向/webroot/web-demo目录indexindex.html;}}
mkdir/opt/webrootmkdir/webrootchown-Rwww.www/webrootchown-Rwww.www/opt/webroot/[www@~]$touch/webroot/web-demo
③执行脚本测试部署：
[www@master~]$./deploy.shdeploycode_getgitpullcode_buildweb-demo_123_2017-06-26-12-18-09.tar.gz100%1214KB1.2MB/s00:00web-demo_123_2017-06-26-12-18-09.tar.gz100%1214KB1.2MB/s00:00web-demo_123_2017-06-26-12-18-09.tar.gz100%1214KB1.2MB/s00:00pre_deploy,cluster_node_remove192.168.3.12HTTP/1.1200OK192.168.3.12WebTestOK!cluster_node_addgroup1,cluster_node_remove192.168.3.12group1,cluster_node_remove192.168.3.13/deploy/config/web-demo/other/192.168.3.13.server.xml:NosuchfileordirectoryHTTP/1.1200OKgroup1_test,192.168.3.12WebTestOK!cluster_node_add
修改代码，测试回滚效果
测试回滚，页面再次回到修改前，说明回滚成功
运维与自动化系列④自动化部署基础与git
自动化部署基础与git
一：上一篇的代码是保存在本地，但是在生产环境当中是由版本控制进行代码管理，以便于发布代码和回滚，一般是使用gitlib比较多，另外还有用svn的公司，趋势是git为主，因此本文以git为使用对象
1.1：在git服务器新建一个web组和项目web-demo：
准备web页面并提交至git服务器(此处我用一个简单的html项目，大家如果没有现成的项目可以自己建一个简单的index.html页面即可)：#准备提交代码目录
#mkdir/source/web/web-demo-p#准备一个项目然后提交至git服务器将项目上传到/source/web/web-demo目录
[www@masterweb-demo]$pwd/source/web/web-demo[www@masterweb-demo]$lltotal20drwxr-xr-x6wwwwww4096Jun613:46assets-rw-r--r--1wwwwww1150Jun617:59favicon.icodrwxr-xr-x2wwwwww4096Jun615:32images-rw-r--r--1wwwwww4323Jun616:19index.html#chown-Rwww.www/source#su-wwwcd/source/webgitconfig--globaluser.name"reblue520"gitconfig--globaluser.email"reblue520@163.com"gitconfig--globalcolor.uitruecd/source/web/web-demogitinitgitadd*gitcommit-m'web-demoall'gitremoteaddorigingit@192.168.3.198:web/web-demo.gitgitpush-uoriginmaster#确认代码提交成功
1.3在部署机准备目录环境：
[www@masterweb-demo]$pwd/source/web/web-demo$gitshow#获取最近更新的版本信息[www@masterweb-demo]$gitshow|grepcommit|cut-d''-f2#只获取版本号91d09cc28f48803d8795f62d925de70f192daeda[www@masterweb-demo]$VERSION_L=$(gitshow|grepcommit|cut-d''-f2)[www@masterweb-demo]$echo${VERSION_L:0:8}#切片取固定长度91d09cc2
1.4.3：在各web服务器准备以下目录：#web服务器操作
#mkdir/opt/webroot#保存代码的目录#chownwww.www/opt/webroot/-R#mkdir/webroot#生成配置文件的web主目录，下面是项目的工作目录，比如/webroot/web-demo#chownwww.www/webroot/-R$touch/webroot/web-demo1.4.4：脚本改造如下，主要实现从git拉取代码再部署至服务器：
1.5运行部署脚本：
1.5.2测试修改代码后能否正常获取最新代码，并部署成功#在自己的项目里面修改代码然后提交至git服务器
[www@masterweb-demo]$pwd/source/web/web-demo[www@masterweb-demo]$vimindex.html[www@masterweb-demo]$gitadd"index.html"[www@masterweb-demo]$gitcommit-m"editindex.htmladdwww.chinasoft.com"[master7886914]editindex.htmladdwww.chinasoft.com1filechanged,2insertions(+),2deletions(-)[www@masterweb-demo]$gitpushoriginmasterCountingobjects:5,done.Deltacompressionusingupto2threads.Compressingobjects:100%(3/3),done.Writingobjects:100%(3/3),324bytes|0bytes/s,done.Total3(delta2),reused0(delta0)Togit@192.168.3.198:web/web-demo.git75463f1..7886914master->master