企业官网建设流程全解析

1. 链路聚合到底在解决什么问题

1.1 先别急着堆带宽，看看流量到底卡在哪

接触过中大型机房或者折腾过NAS的朋友应该都有这种经历：服务器业务上来了，单个千兆网口带宽跑满，业务监控里网卡流量曲线贴着上线走平，CPU还没吃满，但用户已经明显感觉到慢。这时候很多人的第一反应是：网卡换个万兆的不就完了？但实际情况往往是：换万兆网卡要动交换机的光口模块、要换线缆、要改光模块类型，整套下来成本不低；而且有时候单块万兆卡跑满之后，流量一增长，瓶颈又来了。

链路聚合（Link Aggregation）解决的就是这种“单链路带宽到达上限，但业务还要继续扩展”的问题。它的核心动作很简单：把服务器上的两条、四条甚至八条物理网线捆绑成一个逻辑端口，对外表现为一个IP、一个MAC、一个逻辑链路，对内则把流量分散到多条物理链路上同时传输。听起来就像是把四条车道并成一条更宽的“虚拟车道”，但实际机制没那么简单，这也是为什么很多人在配置完聚合之后，发现带宽并没有翻倍，反而出现各种奇怪现象。

说链路聚合适合谁，我觉得是这么几类人：机房里管服务器的运维工程师，给公司搭建内部存储或虚拟化平台的技术人员，还有家里搞了NAS、又觉得千兆网口不够用的DIY玩家。它解决的问题是“多条链路怎么配合着用，而不是一条堵死、一条闲置”。

1.2 聚合的价值不只是“加带宽”，更是高可用

很多人一听到链路聚合，第一反应就是“哦，把两个千兆网口绑起来，变成两千兆”。这个理解对了一半，但很容易害了你在选型时忽略更重要的另一半。

链路聚合在行业里的正式标准是IEEE 802.3ad，后来升级为802.1AX。它定义了两个层面的能力：一是流量负载分担，二是链路冗余。负载分担就是把流量分摊到多根物理链路上，提升整体吞吐；链路冗余则是当其中一个成员口断线、网线松动、对端设备故障时，流量自动切换到其余的健康链路上，整个过程通常控制在毫秒级甚至更低，对业务基本无感知。

这点在虚拟化平台里特别关键。比如一台物理机跑了二十台虚拟机，上面承载着公司ERP系统、数据库和文件共享服务，如果只靠一块网卡顶着，网卡或者网线一坏，所有业务全部中断，哪怕虚机有高可用机制，也架不住宿主机网络完全失联。而做了聚合之后，至少两块网卡互为备份，坏一块，另一块还能继续扛。所以我会说，链路聚合的架构价值远大于单纯的带宽叠加，在规划阶段就应当把它当作“服务器接入层的冗余策略”来考虑，而不是简单的“提速手段”。

1.3 什么情况下不建议用链路聚合

这里必须先泼一盆冷水。链路聚合不是万能的，有些场景下做了反而麻烦。

首先是单条大流量业务。如果一台服务器只跑一个FTP大文件传输任务，或者是单线程的备份任务，那么无论你怎么聚合，这条TCP连接的流量都只会走其中一条物理链路，带宽上限等于单条物理链路的速度，不会因为你聚合了四条就变成四倍。根本原因在于负载分担是“按数据流”分摊而不是“按字节”分摊，同一会话的数据包必须走同一条链路，否则接收端顺序就乱了。这个后面我会专门展开讲哈希算法，这里先记住结论：聚合主要解决“并发会话数量多、总带宽需求大”的场景，而不是“单流带宽大”的场景。

其次是设备不支持的场景。如果交换机是老型号，不支持LACP协议，或者两个端口分属不同的板卡、不同的ASIC芯片，强行做静态聚合很容易出现报文乱序、单播风暴等问题。有些低端交换机所谓的端口汇聚，其实就是把两个口电气上绑在一起，不做会话保真，跑个VoIP或者视频会议就会断断续续。还有一种是已经发生了拥塞的网络：链路聚合本身不增加交换容量，它只是让流量走更多路，如果交换背板带宽本身就不够，聚合只会把拥塞面扩大，而不是消除。

所以，链路聚合的正确启动姿势，不是“我觉得网口不够用”，而是“我的并发业务量确实超过了单链路容量，或者我对物理链路的可靠性有硬性要求”。

2. 聚合成败的关键：标准、模式和协商机制

2.1 从802.3ad到LACP：一个协议的前世今生

聊链路聚合，绕不开两个词：静态聚合和动态聚合。动态聚合依赖的协议就是LACP（Link Aggregation Control Protocol，链路聚合控制协议），它最早定义在802.3ad里，后来802.3ad并入了802.1AX。LACP的核心工作是让链路两端的设备“商量着来”：谁发起协商、谁是主动方、谁能加入聚合组、谁的优先级更高、链路断开时怎么感知，全部通过LACP报文（LACPDU）在成员链路上周期性传递。

静态聚合里，网络管理员在两台设备上手动指定哪些端口加入某个聚合组，端口之间不做协商，只要物理连通就认为链路可用。静态的好处是没有协商开销，配置简单，在一些不支持LACP的嵌入式设备、工业交换机上仍然有存在价值。但它有个致命缺陷：如果对端设备把端口错误地配置成了不同的聚合组，或者干脆忘了配置，那链路不会报错，数据就直接以普通单链路的方式跑，可能会导致广播环路、MAC地址飘移等问题，排查起来很困扰。

LACP则会在成员口上持续发送LACPDU，对端收到后如果参数匹配（系统优先级、端口优先级、聚合Key等），就会把该端口标记为“可聚合”，最终把端口状态置为“选中”（Selected）。如果某个成员口的协商参数不匹配，它会被标记为“未选中”（Standby / Unselected），这时候链路虽然物理连通，但不会转发业务数据。这一点是排查聚合故障最核心的观察点，后面我会反复提到。

选择动态LACP还是静态聚合，我的建议是：只要能支持LACP，一律优先用LACP。因为LACP提供了对端检测能力，物理链路一断或者参数一变，交换机端能立刻知道，并重新计算可用成员口，故障切换更可靠。静态聚合适合那种对端设备非常老旧、或者你就是要固定两端口不许协商的极简单场景，但这类场景现在真的不多了。

2.2 负载分担算法：为什么链路聚合不是“1+1=2”

这是最多人踩坑的地方。链路聚合不等于把两根千兆网线变成一根“两千兆”的网线，它只能做到多链路并行，而并行到什么程度，取决于负载分担算法。

常见的负载分担算法有基于源MAC、基于目的MAC、基于源目的MAC组合、基于源IP、基于目的IP、基于源目的IP组合，还有基于四层端口（TCP/UDP端口）的组合。不同厂商的叫法略有差异，思科叫load-balance，华为/华三叫hash算法、负载分担方式，Linux里则是通过模式（mode）和xmit_hash_policy这两个参数来控制。

这里要特别注意：负载分担基于哈希算法，同一个会话（比如一台PC访问某台Web服务器的长连接）会对应一个固定的哈希结果，所有数据包都会走同一条物理链路，目的是保证数据的时序一致性。如果不同会话被哈希到不同的链路上，这就是我们希望看到的“流量分摊”。但如果所有应用都把流量打到少数几个大会话上，哈希分布就会出现偏斜，可能四条链路里只有两条在跑，剩下两条空着，整体带宽就是“2+0+0+0”而不是“1+1+1+1”。

我把常见算法的适用场景整理成表格如下：

此外还要注意，负载分担算法必须两端设备配置一致。我之前遇到过这样的情况：交换机端配的是IP哈希，但服务器端Linux bonding设置的xmit_hash_policy是layer2，结果协商是成功的，链路也是Up的，但流量分布极不均匀，因为交换机按三层哈希算出来的转发路径，和服务器按二层MAC算出来出口根本对不上。这个细节如果不看两端配置，单看聚合口状态，永远查不出问题。

2.3 两端配置一致性清单

链路聚合一旦配置不对，最常见的现象就是“物理上都通，但业务上不通”或“时通时断”，原因往往出在配置不一致。我给你列一个实际项目里反复核对过的清单：

• 成员口速率和双工模式必须完全一致。混合速率（一个千兆口和一个万兆口）除非设备明确支持，否则不要做聚合。
• 各成员口的VLAN配置必须一致。如果做的是Trunk口聚合，允许的VLAN列表必须逐口核对，少一个VLAN，对应业务就直接不通。
• 物理口属性（Access/Trunk/Hybrid）必须一致，ACCESS口要指定相同PVID。
• 聚合模式一致：一端LACP，另一端也必须LACP，别一端动态一端静态。
• 负载分担算法一致：两端都使用同一种哈希策略，避免因算法不同导致流量漂移。
• 两端系统优先级/端口优先级设置合理，尤其在多链路汇聚到同一对端时，保证选举出的主链路稳定。

这条清单我一般会打印出来，每次做聚合项目都逐项打勾。很多人做完聚合说“不通”，十有八九就是VLAN或链路模式没对齐，而不是聚合协议本身的问题。

3. 我在实际项目里的完整实操记录

3.1 场景需求与拓扑设计

前阵子给某公司的一台数据库服务器做网络升级，场景很典型：这台服务器跑了生产数据库和文件同步服务，两个应用并发会话非常多，但千兆单网卡已经持续跑满几个月，监控里丢包率开始上升。要求在不更换服务器网卡和交换机板卡的前提下，把总带宽提高到2Gbps以上，同时要保证任何一条物理链路故障时业务不中断。

我设计的拓扑很简单：服务器上有两个光口万兆网卡（不换卡，只是启用），分别接到同一台交换机的两个万兆口上。交换机端口和服务器网口速率一致，都是万兆，做二端口LACP动态聚合。为什么选万兆口而不是继续用千兆口聚合？因为两个千兆口聚合成2Gbps，实际上受限于PCIe总线、网卡驱动和Hash分布，稳定跑满也就1.6~1.8Gbps左右，而且数据库生产环境对时延有要求，千兆聚合的收益不够明显。万兆口聚合成两条链路，即使哈希偏斜，单流也能跑满万兆，多流场景更是轻松覆盖现有负载。

3.2 Linux服务器侧bonding配置

服务器操作系统是Linux，选用的聚合方式是bonding，对应驱动是bonding模块。我用的配置方式是NetworkManager加nmcli，这样重启后配置不会丢，比直接写/etc/network/interfaces更可靠（如果你用的是systemd-networkd，思路也类似，但命令不同）。

先查看当前网卡名称和状态：

ip link show

假设两个物理口叫eno1和eno2，创建一个bond0，指定模式为802.3ad（即mode 4，对应LACP动态聚合），并设置xmit_hash_policy为layer3+4，让哈希到IP和端口层：

nmcli connection add type bond ifname bond0 con-name bond0 mode 802.3ad miimon 100 xmit_hash_policy layer3+4

然后分别把两个物理口绑定为bond0的从口（slave/port）：

nmcli connection add type ethernet ifname eno1 con-name bond0-port1 master bond0 nmcli connection add type ethernet ifname eno2 con-name bond0-port2 master bond0

接下来设置bond0的IP地址（以静态IP为例）：

nmcli connection modify bond0 ipv4.method manual ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.1 ipv4.dns 192.168.10.1

最后激活配置：

nmcli connection up bond0 nmcli connection up bond0-port1 nmcli connection up bond0-port2

这里有几个我在实际配置中特别注意的点。第一，miimon=100是链路监测频率，单位毫秒，即每100毫秒检测一次对端是否在线，这个值不宜太大，否则切换时间过长；也不宜太小，否则误报频繁。生产环境我一般用100。第二，xmit_hash_policy有layer2、layer2+3、layer3+4等几个选项，如果你对端交换机配置的是IP哈希，那服务器端就用layer3+4，两端才能对齐。第三，刚创建bond0时，物理口会瞬间down/up一次，这是因为从口成功加入聚合组后由bond驱动接管，属于正常现象。

3.3 交换机侧LACP配置

交换机厂商不同，命令风格略有差异，但思路一致。记录下我用过的华为风格的配置过程，思科也类似，只是命令关键词不同。

进入系统视图，创建聚合口Eth-Trunk 1，并指定为动态LACP模式：

interface Eth-Trunk1 mode lacp-static

注意，华为里“lacp-static”就是动态LACP模式，命名有点反直觉，别被“static”这个词误导。思科里对应的是channel-group 1 mode active，active表示主动发起LACP协商，passive是被动方。

然后把两个物理口加入聚合组：

interface GigabitEthernet0/0/1 eth-trunk 1 interface GigabitEthernet0/0/2 eth-trunk 1

如果这两个物理口需要承载多个VLAN，比如做Trunk口，还要在物理口或聚合口上配置trunk允许列表，务必两个成员口的VLAN配置完全一致，否则VLAN成员关系会错乱。我在生产项目里就会反复核对这条，很多“聚合后某些VLAN不通”的故障其实就是这里配置漏了口子。

再设置系统优先级和端口优先级，确保选举稳定：

lacp priority 100

系统优先级默认是32768，数值越小越优先。如果只有一台交换机和一台服务器对接，优先级其实影响不大；但如果是堆叠环境或多设备互联，就需要规划主备角色了。

3.4 验证与状态确认

配置完成不等于聚合成功，必须看状态。服务器侧，我一般这么验证：

cat /proc/net/bonding/bond0

这个文件会显示bond0的当前模式、成员口列表、各成员口的链路状态、以及从口是否被“up”标志标记。正常情况应该看到每个从口都是MII Status: up，并且有Bonding Mode: IEEE 802.3ad Dynamic link aggregation字样。

其次用ethtool确认物理链路协商结果：

ethtool eno1 | grep -E "Speed|Duplex|Link detected" ethtool eno2 | grep -E "Speed|Duplex|Link detected"

两个口都必须显示同样的速率和双工，比如Speed: 10000Mb/s，Duplex: Full，Link detected: yes。如果两个口速率不一致，聚合组可能在交换机侧拒绝其中一个口加入，或者协商状态异常。

交换机侧我常用的验证命令：

display eth-trunk 1 display lacp statistics Eth-Trunk 1 display interface Eth-Trunk 1

重点看聚合口状态是否为Up，两个成员口是否都是“Selected”。如果某个成员口显示“Standby”或“Unselected”，说明协商有问题。再配合display lacp statistics查看LACP报文收发计数，如果只有发出没有收到，说明对端可能没有启用LACP或者参数不匹配。这个排查思路我后面还会展开。

4. 常见故障与排查实录

4.1 现象一：聚合接口起来了，但只有一条链路在跑流量

这是我在项目里遇到最多的现象。服务器bond0显示两个从口都是Up，交换机侧两个成员口也都是Selected，但查看实际吞吐，发现其中一个口的流量占比超过90%，另一个几乎空闲。

排查步骤按顺序来：先看两端的Hash算法是否一致。服务器端bonding的xmit_hash_policy可能默认是layer2，而交换机配置的是基于IP或端口的哈希，两边算法不匹配，单向流量自然只会落到某一条约束路径上。解决方法是把两端算法对齐，比如统一到layer3+4 / 四层端口哈希。

再看业务种类。如果这套聚合承载的业务是若干条大流量长连接，比如数据库实时同步、备份恢复、视频流拉流，这类会话数量小但单会话带宽大，哈希很容易把几个大会话分到同一条链路上。这不是故障，而是哈希分布的数学特性。想减少偏斜，可以尝试调整交换机侧的负载分担策略为更细粒度的四层端口哈希，或者在服务器侧对多队列网卡做RSS调优。但根治这种偏斜，有时候只能靠增加物理链路数量来分散会话，或者把几个大流量应用拆分到不同物理网卡上。

还有一种是物理层光模块或线缆质量问题导致某条链路实际协商速率降级。比如两个万兆口，一根线是万兆，另一根线虽然能通但插成了劣质跳线，协商到千兆甚至百兆，聚合口状态可能是正常的，但带宽被拖低。检查方法还是ethtool看Speed和Duplex，这条必不可少。

4.2 现象二：LACP协商失败，成员口一直卡在“未选中”状态

有一次现场排查，服务器bond0两个口一个Up一个Down，Down的那个物理纤芯明明插好了，但交换机侧对应成员口状态就是一直不变成Selected。我把交换机端口的LACP统计打出来，看到这个口只有发送的LACPDU计数，接收计数几乎为零。服务器侧抓包发现，服务器其实也在发LACPDU，问题出在两端系统优先级、端口优先级或聚合Key不一致。

LACP协商里有一个关键参数叫聚合Key，它决定了哪些物理口可以聚合在一起。如果服务器端的两个网口不在同一个bond组内（比如不小心把其中一个口配置成了独立网口的IP），或者交换机的两个物理口不属于同一个Eth-Trunk组，那么即使物理上能互发LACPDU，两端也不会把端口选中。这种场景下，检查配置就是唯一出路：服务器上用ip link确认两个物理口都属于bond0且没有单独配置IP，交换机上确认两个端口都加到了同一个Eth-Trunk里。

还有一个容易忽略的因素是端口优先级。如果服务器同一块bond里有四块网卡，其中两块接到了交换机A，两块接到了交换机B，而交换机A、B分别运行不同的LACP系统（系统ID不同），那么必须保证同一个聚合组内的所有成员口对端系统ID一致。我曾见过一台服务器为了冗余同时接两台交换机，结果没有做跨设备链路聚合，导致一边的成员口永远在Standby状态。其实这时候要么做跨设备链路聚合技术，要么老老实实只接一台交换机，把另一台留给其他业务。

4.3 现象三：聚合配置没问题，但存储业务时延依旧很高

排除LACP协商问题后，时延高往往和负载分担没有直接关系，而是聚合口内部的报文处理机制、交换机端口的缓存策略以及成员口之间的物理路径差异所致。

最典型的情况是一条成员口走的是交换机板卡A，另一条走板卡B，两块板卡的处理时延不一致，或者两个端口分别分布在不同的线卡交换芯片上，导致跨芯片转发延迟增大。如果是存储网络（比如iSCSI、NFS、CIFS），对单会话时延非常敏感，即使总带宽足够，时延抖动也会让上层协议重传，最终看起来就是“聚合之后反而更卡了”。

另一个隐蔽原因是巨型帧（Jumbo Frame）配置不一致。如果服务器bond0的MTU是9000，但交换机的某个成员口MTU还停留在1500，那么当这个成员口转发大帧时会被分片或丢弃，应用层表现为随机时延或偶发故障。排查时务必要在两端所有成员口统一MTU值。

我遇到过更奇葩的情况：两个物理口接到交换机之后，因为其中一个口的对端光模块质量差，协商成功率低，频繁触发LACP重新协商，每次协商期间聚合口会短暂进入重新计算状态，哪怕只持续几十毫秒，存储业务的读写请求也会因此卡顿。后来把劣质光模块换掉，时延曲线立刻恢复正常。所以，聚合排查永远不要只盯配置，物理层光功率、光模块、线缆质量也值得排查。

4.4 现象四：Windows NIC Teaming与Linux bonding混用时的坑

跨平台混用并不少见。比如一边是Windows Server的NIC Teaming，另一边是Linux服务器的bonding，或者Windows服务器上同时跑Linux虚拟机的网络桥接，这时候容易出现兼容性盲区。

Windows NIC Teaming有两种核心负载分担模式：Switch Independent（交换机无感知）和Switch Dependent（交换机感知）。其中Switch Independent模式又分地址哈希、动态、Hyper-V端口等几种，它在服务器内部直接做转发而非依赖于交换机聚合协议。这种模式下，其实并不需要交换机侧做LACP，只要你把服务器上两块网卡接到的两个交换机端口都划到同一个二层网络（比如同一个VLAN）就行。如果这时候你又在交换机上把这两个口配置成了Eth-Trunk并要求LACP协商，反而两边各说各话：服务器认为自己在做独立链路负载均衡，交换机却要求LACP，两边永远谈不拢。

我的建议是：Windows侧如果用的是Switch Independent动态模式，交换机侧就不要配置任何聚合，直接把两个口当作普通口用，靠服务器端自己分担。而想在交换机上做LACP，那Windows侧必须选择Switch Dependent模式（对应就是LACP），且两个网卡要接到同一台交换机的同一个聚合组端口里。这种模式命名上的混乱，是我见过很多人栽跟头的地方。

4.5 速查表：5个最常见的聚合故障原因及排查命令

实际排查时，我认为“抓包 + 看计数器”是不可或缺的。用tcpdump在任意一个成员口上抓LACPDU，确认周期性收发正常，再来分析上层业务流量的分布，很多问题都能快速定位。

5. 进阶技巧与我的经验总结

5.1 诊断工具链条与现场排查顺序

链路聚合的故障诊断不能靠肉眼，要建立一个固定的排查链条。

第一步先看物理层。对每个成员口执行ethtool，确认速率、双工、Link detected三个字段是否符合预期。只要有一个口速率不一致，后续全都白看。

第二步看聚合层。Linux下读/proc/net/bonding/bond0，华为设备上执行display eth-trunk，把成员口状态、聚合模式、系统ID一一对照。

第三步看协议层。确认LACP报文在正常周期发送和接收。可以抓包看LACPDU的速率，正常是每1秒或每30秒一次（取决于短超时/长超时模式）。如果对端收不到，基本就是模式不匹配或链路本身不通。

第四步看流量层。用ip -s link、ifconfig或者交换机侧display interface查看每个成员口的流量统计，判断Hash分布是否合理。两个口的收发字节数如果差异巨大，就回到Hash算法上排查。

第五步看应用层。若业务时延高，需要结合抓包分析TCP重传、乱序，以及中间是否有分段或丢包。我通常会同时打开服务器侧和交换机侧的端口镜像，把聚合口流量拉到分析机上对比。

5.2 踩过几次坑后，我的“聚合前检查清单”

以下这些内容是我在实际项目里反复被坑之后沉淀下来的，每次做链路聚合之前都会过一遍：

1. 两端成员口的速率、双工、MTU、VLAN属性是否完全对齐。
2. 两端是否都使用LACP动态聚合，还是都使用静态聚合，不要混搭。
3. 两端Hash算法是否一致，尤其注意Linux bonding里xmit_hash_policy和交换机load-balance命令的对应关系。
4. 确认成员口内没有配置独立的IP或路由条目，否则会出现路由黑洞或链路心跳冲突。
5. 确认没有防火墙、iptables规则拦截LACPDU（有些安全加固脚本会拦截固定端口，LACP报文基于组播地址，但某些策略仍可能误阻）。
6. 如果是跨设备冗余，确认使用的是专门的跨设备链路聚合方案，而不是把普通聚合硬接到两台交换机上。
7. 使用短超时模式还是长超时模式，和业务切换诉求匹配。短超时（1秒）检测快，但LACPDU频率高，占用少量带宽；长超时（30秒）省资源，但故障切换相对较慢。
8. 操作前备份交换机配置和服务器网络配置，并准备好回滚脚本或命令。

5.3 关于Hash算法、多队列和现代网卡

链路聚合做到后期，你会发现真正的性能瓶颈往往不在聚合协议本身，而在于网卡的多队列能力、中断亲和性以及驱动配置。现代万兆网卡普遍支持RSS（Receive Side Scaling，接收侧缩放），它可以将不同数据流的哈希分配到不同的CPU队列，让多核CPU分摊收包压力。如果bonding做在RSS之上，还要考虑聚合哈希与RSS哈希之间的协作关系。我项目里的经验是：先开启网卡自身的多队列能力，再做bonding的layer3+4哈希，配合irqbalance或手动CPU亲和性，才能同时压满多条物理链路的多核吞吐。

对于一些高性能场景，比如DPDK用户态转发，链路聚合往往就不再依赖内核bonding，而是通过网卡自身的硬件链路聚合特性或专用的负载均衡方案来实现，这属于另一个量级的话题。但核心原则没变：精确的会话保真 + 尽量均匀的流量分布 + 成员的快速故障感知。

再分享一个小技巧：遇到极端Hash偏斜却没法改算法的场景，可以在服务器端为业务配置多个IP地址，让业务流量分散到不同的源IP上，人为改变哈希结果。这招在数据库多实例、容器多副本场景里尤其好用，比换算法简单直接。

我在实际项目中踩过最狠的一次坑，就是只看了聚合口状态全绿就宣布上线，结果第二天业务高峰期流量全涌到一条链路上，四条聚合链路总带宽只跑出了单链路的水平。后来复盘发现，就是交换机Hash配置和服务器bonding配置不一致，两边都以为自己在用四层哈希，实际上交换机只配到了二层。所以从那儿以后，我把“核对两端Hash策略”写进了所有聚合项目的上线检查单里，建议你也把这个动作当成肌肉记忆。

链路聚合这个技术，说大不大，说小不小，但它几乎是服务器网络架构里最容易产生“看起来简单、做起来处处是细节”的技术之一。把基础原理搞清楚，把两端配置核对到位，再配合一套稳定的排查手段，你就能让那些物理链路真正地协同工作，而不是各自为政。