陌生环境下部署的思路

由来

本篇的由来不是来自偶然，但是如果说是必然又会显得很唐突。在现场实施部署工作中，难免会遇到各种个样“突发”的情况，原因不外乎信息的不对称，提前调研不足或者根本没有提前调研。在有就是没有提前调研的环境。说到这块想起做过三个项目的场景。

场景一

东北某省的运营商项目当时在机房现场施工，一家A企业现场施工，甲方给划定了区域，需要乙方自行完成机柜的安装、线路的铺设、设备的上架、设备调试、操作系统的部署、业务系统的部署、业务系统的调试。机柜的安装成了一道非做不可的工作，B企业自行按甲方要求选择了图腾标准机柜，从图腾官网下单沟通，从杭州发货到机房整整发了10天左右，到了后，电梯刚好进不去货梯，机房在6楼，机柜相对比较大和重，从外面找了三个人花费了500元，加上施工人员，四个人从一楼搬到了6楼机房，放置到了甲方指定的区域，准备安装机柜的时候，甲方人员验收中指出，机柜超出了本排其他机柜的高度，不能使用。沟通无果后，又找到原来的三人花费了500元搬了下去，发回厂家重新进行了换货处理。上架设备的时候发现电源模块不对，机房提供直流电，设备带的是交流电源模块。需要返场换货。

场景二

西南某省的国家电网机房现场施工，企业B现场故障处理，个人电脑不能带入机房，数据需要刻录至光盘带入，施工人员按要求带了两张光盘业务系统光盘和操作系统光盘，公司得到的初步研判是业务可能是崩溃了，到机房后重新启动一下业务系统或者最严重的情况下重启一下服务器后再重启业务系统。到现场后发现硬盘故障，未设置RAID，硬盘整个就1块，基本数据尽丢，机房不允许携带硬盘出机房，公司从供货商处采购硬盘后，发到机房，施工人员一下子蒙了，unix操作系统，需要按公司要求编译安装。没有对应的操作文档。对于习惯了windows操作系统的用来来说，编译安装无图形化界面的unix系统成了一道看似不可以逾越的天堑。

场景三

某国企业务系统国产化系统改找，将系统从原有的Centos 7版本迁移至国产系统，按照测试环境编制了自动化部署脚本，分测试和正式两套环境，从客户那块获取到的消息是腾讯操作系统、测试环境分配下来看着是华为的欧拉操作系统，正式环境抵达现场后都还没有分配下来，待了一天要下班的时候，环境开通成功，银河麒麟操作系统，全程再浏览器中操作部署，没有yum源配置，软件编译用到的依赖库都没有。自动化部署脚本没有一个成功运行。手动安装部署了十几台服务器，硬是把原计划一天干完的活，给干成了一周。

整体的随想

以上三个场景，用沟通和去现场就可以有效的避免很多不必要的无效工作，毕竟有的工作有事后（也就是相同类似的项目）但是有的项目没有事后一说（一次性项目）。
场景一：提前去机房调研一下目前机房的环境，机柜的型号和长宽高的尺寸、设备使用导轨还是托盘、机房供电（交流/直流）、设备功率、电缆的平米测算、网络的类型（光纤/网线），机柜采用本地化采购，当地供货商负责提供机柜，还可以现场确认机柜型号，沟通好的情况的话还可以提供安装服务，货梯是支持标准机柜的出入。机柜费用比官网贵出了200元左右，但是可以省去很多不必要的麻烦。机柜当天采购当天送货。
场景二：客户方有对接人员，本公司去客户现场之前电话沟通了解一下设备的信息，是否能登录服务器？是否能ping通服务器？服务器面板灯是否正常？初步排除定位故障，像硬件告警基本都是可以通过指示灯判断出来的，针对远程判断出硬盘故障后，采购硬盘，使用相同型号的服务器上，编译操作系统、部署业务程序（公司资源相对丰富可以及时协调人员和处理异常），确认无误后，携带硬盘奔赴现场，换下异常告警硬盘，调试一下程序配置。
场景三：提前跟客户确认操心系统的型号，部署过程按最原始的环境开始部署，考虑到无软件源的情况，可以自行搭建软件源（确认系统型号的前提下）。脚本中优先考虑shell脚本，其次python,再次goland/ansible/pupet等脚本。现场环境的水不知道深浅。但是linux环境是确认的，shell脚本是可以保证执行的。

经验

经验这个东西，没法去定义，在企业中是企业的组织过程资产，以知识形式留存，但是更多的时候是在工作中的言传身教。要做一个项目做一件事先去了解这个事，这个项目的由来、背景、目的。这块可以从商务层面或者合同和招投标书中获取信息。大的背景了解了，再去具体的业务线去跟踪。部署的形式：私有云、共有云、专有网、互联网，数据交换、数据存储、数据处理、数据展现、数据交互。进而自然而然地到交付物环节：实施、部署、调试、测试、培训、使用、维护、售后工作。从而去开展各环境的工作，一个项目有整体计划，各各环节又应该有本环节的计划。计划就是将不确定的事项归置、规范，使项目的进度可控。把风险系数降低到我们认为的最小。这个是相对的，就像开始提到的经验。