藏经阁一起读（7）读《云服务器运维之Windows篇》，你有哪些心得？

学习下

哦

可以

哦

哦

哦

学习学习

这本书Windows 服务器运维及实践的技术结晶，分别展开介绍了云服务器的运维、监控、问题排查、内核调试等方面，从技术原理到线上真实案例， 是众多阿里云技术专家多年在云服务器领域的经验与总结。越来越多的客户选择迁移上云。企业客户 在把线下业务迁移到云上之后，需要解决的关键问题就是如何用好云上资源，如 何解决弹性的问题，如何运维云服务器，云上服务器遇到问题后该如何解决。目 前在云上对 Windows 服务器的需求正在飞速增长，掌握 Windows 运维的重要性非常重要，这本书就非常适合有这方面需求的大家进行学习！

这本书主要介绍了在阿里云上使用Windows 服务器的运维操作和最佳实践，包括使用云助手批量运维服务器、使用 Windows 服务器自助诊断功能， 以及使用Windows 镜像及迁移上云的最佳实践。Windows 服务器的启动、登录过程，远程桌面连接的使用和排查，激活Windows 服务器， 系统时间同步和Windows 更新补丁的过程。包括用性能调试工具WPA 分析CPU、内存等系统性能瓶颈问题，内核调试工具WinDbg 的安装使用， 以及通过内核调试工具排查服务器蓝屏、异常死机等问题。其中云服务器带来的技术和架构优势，使得企业和开发者得以高效选择、运行、维护基础设施， 并充分享受数据可靠性保障、弹性扩展等云计算特性带来的技术红利。经常会遇到一些比较刁钻的问题，凭借对 Windows 服务器 的原理和架构设计的了解，通过长期规模化的运维，解决了诸多技术问题。学习完了《云服务器运维之Windows篇》这本书
可以让我们做到将 Windows 云服务器的技术原理与客户侧疑难诊断案例相结合，希望帮助我们企业在落地云服务器的进程中做好充分的技术准备。

运维行业有句话：“无监控、不运维”，是的，一点也不夸张，监控俗称“第三只眼”。没了监控，什么基础运维，业务运维都是“瞎子”。所以说监控是运维这个职业的根本。尤其是在现在DevOps这么火的时候，用监控数据给自己撑腰，这显得更加必要，有人说运维是背锅侠，那么，有了监控，有了充足的数据，一切以数据说话，运维还需要背锅吗。 常见的运维监控工具： 1、Cacti 2、Nagios 3、Zabbix 4、Ganglia 5、Centreon 6、Prometheus 7、Grafana

这本书是2022年1月第1次印刷，应该是windows云服务器运维方面最新的知识。这本书的作者是阿里云一线的windows云服务器运维专家团队，能作为阿里云的团队专家，专业能力肯定是毋庸置疑的。他们将他们的知识和工作中遇到的问题和解决问题的宝贵经验进行了总结和归纳。相对于Linux系统，Windows底层系统属于黑盒，故其操作和运维存在较大的难度。这本是将Windows云服务器的技术原理、内核调优、迁移上云三方面集于一身更是结合真实案例进行了全面细致的阐述。如果要学习或者解决windows云服务器运维这本书可以起到非常好的知道作用

学习

;lkhv

学习学习

Windows 服务器有多少企业在用？

牛

各位大佬先不要急着踩我，手下留情

重点是

看我对这书有多少自己的理解

一 先看目的

首先得搞清楚目的是啥？是帮你云上Windows服务器运维这方面有哪些坑、你极有可能遇到真实线上的案例监控？我觉得其中最重要的一点，遇到线上的麻烦是很常见啊，但是你得自己系统的总结用合适的工具与调试方法解决才行，以及过程中你自己积累下的宝贵经验教训是不可复制的。

二 基础基础还是基础

我们为啥要选云windows服务器呢？先来看这种windows服务器它是种闭源系统，那我们为啥还是要选它，就是因为它给我们提供管理API很多才选它，所以可运维性上是可圈可点的，再加上本身云上运维的维度和众多产品有关联啊，所以这极大地拓宽了它Windows服务器云上运维就必须要这种了。

好，我们现在确实考虑 Windows 服务器这种运维架构，首先要了解它在哪些面要涉及到啊：

• 1 整机维度：与 Linux 系统没啥区别，ECS为例，即代表着机器本身的开关机状态、平台维护状态、平台安全问题等都是属于的，还包括ECS快照、镜像管理等也是。 
• 2 系统维度：与平台级维度没关系，主要对 VNC 界面（也叫虚拟连接控制台，是各个云厂商提供的基于平台的外挂管理界面）、远程登录（RDP，叫远程桌面协议）、性能监控等进行设计。 
• 3 业务维度：围绕业务本身的生命周期设计修复、灾备、应急等流程，这个跟你公司具体业务结合起来才行。 

• 4 底层维度：这是对云厂商的特性选择云产品进行保障，比如设计一定的事件监控与告警机制，对于相关高可用业务设置自动运维，这个是考察你底层去解决特定问题的能力哦。

• 5 SLA 维度：针对以上所有的维度来说，运维体系中还有最重要的一环就是可用性基线，它是干啥的呢？主要用于评定整体运维的质量与制定持续改进的方向，这一维度也可以通过云监控的自定义大盘配合报警服务来展示。

综上所述，Windows 服务器运维架构看图来理解

三 光说不练假把式

1 整机维度实践

出现故障需要把好的数据进行转移的场景里面

1）一种云盘，它是由平台触发，完成集群迁移的效果，缺点是只能往一个路径迁入

2）第二种就是上图这种打快照，这个比上面高级点，会在固定时间做，假如遇到高峰期，可以立即恢复快照的哈，就跟啥事没发生一样。如何打快照也是有讲究的哈，自己去看

2 系统维度实践

这个更上面比起来，就比较单一了，重要这里我说两种

• 1 安全：安全维度在 Windows 服务器运维领域这个容易被忽略，而阿里云则提供了一个比较便利的方式来构建 Windows 服务器安全屏障，阿里云云安全中心的 Windows 系统漏洞界面下图
• 2 状态：建议使用阿里云云监控的事件告警功能，该功能提供了较为完善的事件列表，初始设计时可以以全部严重级别事件来进行告警，如下图所示，然后在日常运营过程中根据实际情况逐步收敛告警。

3 业务维度实践

这个选择面就宽泛了哈，如果说产品比如自动化，批量化脚本下发工具，但是没有让他们标准化，对于windows运维来说运维成本加大。但是云上的就不一样了，比如这个编排服务提供了基于 Windows Powershell 的命令下发功能，排除了系统本身的影响，提高了业务级的运维能力，与 Windows 服务器自带的计划任务、组策略等系统级运维方式相辅相成，简直妙啊~

3 底层维度实践

主要建立系统事件（比如内部系统崩溃时的告警）与平台事件的优先级才行。一般来说，平台事件优先于系统事件，因为底层传递的信息，会比系统内传递的信息纬度更高、更加精准，虽然在感知灵敏度上比系统本身的告警要低一些，但是综合考虑千万不要一刀切啊；

对于底层维度运维来说，对控制台面板的关注也很关键哦

建议按以下步骤设置 Windows 服务器面板： - （1）对于所有 Windows 服务器类型的 ECS 进行打标（如统一加标签“Windows服务器”）。 - （2）对于所有 Windows 服务器类型的 ECS 进行云监控中的应用分组。 - （3）在企业内部创建的 ECS 规范中声明好创建 Windows 服务器 ECS 应选择的标签与应用分组。

ECS 的控制台面板支持通过标签进行检索，但缺点是只能进行分地域查看，若要实现全地域查看，可以使用“资源组”功能，将 Windows 服务器归入同一资源组中，然后在资源管理器中进行状态检查，实现底层运行状态观察与运维（如微软公司提供的 System Center Operations Manager 解决方案）。

4 SLA 维度实践

两个实践建议： - （1）安全可用性：阿里云直接提供了“安全基线”功能，定期进行基线检查即可从平台维度保证安全方面的 SLA 不下降，如下图

-（2）探活可用性：在 2.1.3.3 节中讲到提前对 Windows 服务器做应用分组，这不仅可在云监控中发挥作用（2.4 节会详细讲到），还可以针对应用分组进行可用云服务器运维之 Windows 篇性监控（路径为“云监控”→“应用分组”→单击对应应用分组即可进入对应分组的可用性监控设定界面）

三 你可用云助手在Windows实例中安装OpenSSH程序

当系统内有自动化/批量安装程序的需求时，可使用云助手在不进入系统的条件下完成。下文以 OpenSSH 程序为例，介绍如何使用云助手在 Windows 服务器系统内部安装程序

1．前提条件

支持 Windows Server 2012 64 位及以上操作系统，确保 Windows 实例中的云 助手可用， 实例需配置公网 IP，实例所在的安全组允许 SSH 协议默认的 22 端口 流量通行。

2．操作步骤

（1）打开云助手控制台，单击“创建/执行命令”按钮，参见图 2-11。 （2）如图 2-14 所示，在“创建命令”对话框中： 选择“命令来源”为“输入命令内容”； 选择“执行计划”为“立即执行”； 选择“命令类型”为“PowerShell”； 云服务器运维之 Windows 篇

在“命令名称”和“命令描述”文本框中输入有意义的语句，如“Install OpenSSH”“安装 OpenSSH”；

四 第二个使用云助手对 Windows 实例文件系统扩容

当云盘（系统盘或数据盘）使用空间不足时，可以扩充云盘的存储容量。下文介绍如何使用云助手，在不停止实例运行的情况下为 Windows 系统扩容云盘。

1．前提条件

先在控制台对硬盘进行扩容，例如在线扩容，数据盘从原来的 30GB 扩容到 60GB。支持 Windows Server 2012 及以上版本系统，支持同时扩容系统盘和多个 数据盘。

注意：硬盘扩容操作有风险，建议先创建快照备份。

2．操作步骤

（1）打开云助手控制台，单击“创建/执行命令”按钮。 （2）如图 2-15 所示，在“创建命令”对话框中：

选择“命令来源”为“输入命令内容”； 选择“执行计划”为“立即执行”； 选择“命令类型”为“PowerShell”；

在“命令名称”和“命令描述”文本框中输入有意义的语句，如“Resize FileSystem”“文件系统扩容”；

五 用户也可选择自助诊断

登录 ECS 实例控制台，选中某个 Windows 服务器实例，在“运维和诊断”子菜单中选择 “诊断健康状态”命令，弹出图 2-18 所示的“实例健康诊断”界面。 在“实例健康诊断”界面，根据需要选择问题场景和诊断范围。  问题场景为“全面体检”：全方位诊断实例的网络状态、磁盘状态等，还支 持同时检测 ECS 操作系统内相关配置。  问题场景为“实例网络异常”：支持单独诊断实例的网络状态。 以“全面体检”为例，在“实例健康诊断”界面，勾选“同时检测 ECS 操作系统内相关配置”复选框，单击“开始诊断”按钮，如图通过所示。系统会通过云助手下发特定的诊断工具，并运行。 单击“开始诊断”按钮后，跳转至诊断结果界面，待诊断结束后若诊断通过则显示上图所示界面，若诊断出现异常，则显示图 2-20 所示界面并给出针对该异常的解释和具体修复建议。

六 windows服务器监控

监控的目的是防患于未然以及通过事后的复盘来完善监控运维体系，以保证生产环境的稳定。通过监控，我们能够及时了解生产环境的状态。一旦出现非预期的隐患，就可以及时预警，或者是以其他方式通知对应的运维人员，让运维人 员可以及时处理和解决隐患，避免影响业务系统的正常使用，将一切问题的根源扼杀在摇篮中。在多数互联网公司中，运维和监控被称为 SRE，再细分一些的运维领域，可能会将监控单独划分出来，称为 NOC，它是业务正常运行中非常重要的一环。

即便国内互联网一线的厂商们，内部也有着林林总总、各式各样的监控系统和运维工具，有的关注业务数据，有的关注服务器的健康状态，有的则面向数据库和微服务特定指标。为了便于各位读者更好地学习并理解本章内容，这里的监 控聚焦在云上 Windows 服务器系统本身的监控。

Windows 服务器场景下，由于其系统需要的负载资源较多，建议根据业务的类型进行告警设计，同时设计优先级。总体来说，有以下几个告警设计原则（包括但不限于）：用于数据库的 Windows 服务器建议将内存使用率及与内存相关的性能指标适当上调，避免告警系统过于敏感导致告警泛滥； - 对于状态类，比如说服务器运行状态、探活状态的监控，建议以平台级→ 系统级来进行监控设计； - 从应用视角出发，我们可以基于 APM 性能监控上的关键链路和指标来好好设计 监控，比如说 APM 上如果显示业务连接超时较多，那就同步设定 Windows 服务器的相关性能指标就可以。

读完这本共 11 章的电子书，大致上分为三篇，第一篇为基础篇，主要介绍在阿里云上使用 Windows服务器的运维操作和最佳实践，包括使用云助手批量运维服务器、使用 Windows 服务器自助诊断功能，以及使用 Windows 镜像及迁移上云的最佳实践。读到第三篇的时候，主要介绍非常有用的调试工具和调试方法，包括用性能调试工具WPA 分析CPU、内存等系统性能瓶颈问题，内核调试工具WinDbg 的安装使用，以及通过内核调试工具排查服务器蓝屏、异常死机等问题。想到了有一次的的排错经验，非常值得纪念。

我记得修复了一个Bug，我们都知道脱壳，首先修改被加壳程序的入口点到程序原来的OEP，然后修改PE程序导入表目录地址为原来导入表地址，或者新建一个节，将这个新节作为导入表节，并将原导入表内容写入新节导入表。 这个过程很简单，OD跟踪，让壳运行到原程序OEP（不一定非得OEP，程序领空导入表一般都是处于还原状态，OEP要知道），这时候可以用PE DUMP脱壳插件或者用LordPe等工具脱壳，程序当前的内存映像被dump出来，里面IAT结构完整很容易被发现。 dump后程序不能正常运行很可能是导入表位置错误（也可能是程序有自校验），因为dump出来的只是内存中的映像快照，导入表目录还是指向壳的导入表，这时，需要用导入表修复软件查找dump出的PE文件原导入表首地址，然后修正导入表目录中导入表的位置，或重建导入表。Import Fix导入表修复软件会新建一个节来保存原导入表数据，并将导入表目录指向新节导入表位置。在搜索导入表时可能导入表被破坏，Import Fix会识别出一些无效的IAT项，可以将其剔除掉。 第一次脱壳的时候就不知道这点，以为直接就可以用了。哈哈。首先得说一下程序调用DLL导出函数的原理，PE调用DLL里的函数，一般是先加载这个DLL模块到它的进程地址空间， 然后在加载后的地址范围内找到每个调用函数的地址，在程序中你可以使用LoadLibrary()这个系统API去动态去加载某个DLL，再通过GetProcAddress()系统API来找到DLL导出的某个函数地址，得到函数地址了你才能使用这个函数。用户DLL被加载后的基址可发生变化，导入的函数地址不是固定的，你不能使用固定的地址。系统DLL虽然基址固定，函数地址固定，但是一般不会直接使用函数硬地址，还是要GetProcAddress()这个API来得到地址，因为XP、win7等每个系统的这些地址是不一样的，会导致兼容性问题。所以，脱壳后修复IAT并关闭ASLR。下面举个简单的案例。

1. 寻找OEP 这个非常简单，就不细说了。 2.加壳程序的IAT 脱壳后如遇到程序无法正常运行（XP环境），可能是因为导入表破坏，需要手动修复。 通过PC文件格式的学习，可以知道导入表的RVA在可选头的DataDirectory数组中存放 图为加壳程序DESCRIPTOR的偏移 18008，大小64 根据节区头的信息定位IAT在第6个节区 .aspack 中

通过节区已知的虚拟偏移与物理偏移可以计算出DESCRIPTOR在文件中的位置。

offset = A008

找到导出表的位置，可以知道导入了两个DLL文件，可以分别计算出Name和IAT的偏移

NAME(1) = 9FC8 NAME(2) = A044

IAT(1) = 9FB8 IAT(2) = A04F

如果对PC头不了解，可以借助PE View进行查看。 就清晰的看到加壳后的程序在启动时导入的函数

3.运行时压缩的原理 在这里插入图片描述 可能存在疑问，为什么脱壳后需要手动修复IAT。

IAT主要用于DLL文件的重定位，IAT的引入相较于 16位dos程序 不再需要包含库文件，而是通过表的形式进行映射。如果IAT不准确，则程序无法执行相关库的函数。

压缩壳对节区进行了压缩，把IAT修改为壳自身的IAT，在解压缩的最后一步会还原IAT使程序可以正常运行，所以脱壳后需要进行IAT的修复。

通过OD查看运行后程序的IAT。

相较于加壳程序的IAT，运行加壳程序后真正的IAT要多的多，如果我们只进行脱壳，而不进行IAT的修复（如下图所示） 程序的IAT是被损坏的

4 IAT修复 使用ImportREC工具，加载处于OEP的程序进程 填写正确的IAT信息 获取到内存中的IAT信息，然后删除无效函数后转存到脱壳后程序中，程序即可正常运行。 PS:windows vista / win7 系统就开始使用ASLR技术防止溢出攻击。使得每次加载程序都加载到一个随机虚拟地址。ASLR依赖于重定位表进行定位，对于EXE程序来说，重定位是可选的，通过关闭ASLR即可解决。

上期活动名单：

三石DD、龙哥手记、t7timf3egkek2

请以上三位同学扫码加群私聊群主收货信息