香港联合管理型IT：一家媒体制作公司的工作分工

简而言之： 香港一家媒体制作公司的两位内部IT专员，对剪辑、存储与交付系统的了解，胜过任何外部服务商在短时间内能学到的程度——但他们大部分时间却花在重设密码、重装笔记本电脑和处理下班后的告警上。联合管理型IT要决定的，正是这些工作中究竟哪一半应该真正交出去。

一位香港媒体制作公司的技术负责人，找来负责IT的两位同事，问了一个简单的问题：你们上周究竟花时间在做什么？答案并不好听。两人加起来重设了九次密码，在一次糟糕的Windows更新后重装了两台笔记本电脑，星期五晚上处理了一通电话——某个邮箱在周一交付前突然停止同步——还追查了一处已经被投诉过四次、位于包装区附近的Wi-Fi死角。他们没怎么做的，恰恰是真正需要他们专业知识的工作：每个剪辑室都依赖的共享存储阵列、必须符合电视台收录规格的交付流程，以及每逢大项目交付就会堆积如山的渲染队列。

这不是一个关于两个人能力不够的故事。这是任何一家成长中的媒体公司，其两人IT团队都会遇到的处境：常规、可重复的工作量超出了可用工时，而又没有别人可以分担。联合管理型IT不是"把IT部门外包出去"的委婉说法。它是对一个具体问题的刻意回答：这些工作里，哪些真正属于本公司的特有知识，哪些其实是香港每家公司都会遇到、也早已有成熟解法的问题，理应交给一个本就全天候运转的团队。Brocent自2007年在北京成立起就一直提供管理型IT服务，2016年起在香港设立办公室，2021年起总部设于新加坡——而下文所描述的模式，正是Brocent在众多技术架构清晰分为"专业侧"与"普通企业侧"的公司里反复见到的情形。

香港的媒体与内容制作行业

香港的媒体与内容制作行业涵盖范围很广：后期制作公司、广告与品牌内容工作室、企业宣传片制作商、广播与流媒体供应商，以及自带内部制作部门的营销代理公司。无论具体产出是什么，多数公司都有一个共同点：其技术架构清晰地分成两个截然不同的部分。一部分是专业的、面向制作的——每个剪辑工位同时读写的共享高带宽存储、运行特定硬件上高负载软件的剪辑与调色工作站、一套渲染或转码流程，以及围绕客户、电视台或平台各自收录规格所建立的交付流程。另一部分是普通的、面向企业运营的——笔记本电脑、邮箱、存放合同与发票的共享盘、视频会议、财务系统，以及工作室自身网站或CMS。

专业侧的部分，对外部服务商而言确实难以在短时间内接手。媒体存储系统的配置围绕着特定编码格式、特定项目结构与特定交付期限展开，一家普通IT服务商没有理由已经理解这些。而企业侧则恰恰相反：它几乎与香港任何一家百人规模公司的运作方式没有分别，一家管理型IT服务商每天都在处理成千上万个类似的工作负载。多数处在这种情况下的公司，问题并不是缺乏优秀的IT人才——而是他们那些在专业侧极为出色的IT人才，最终把大部分时间都耗在普通侧，只因为没有别人被分配去做这件事。

具体场景：110名员工、两位IT专员，以及一套以截止日期为核心的技术架构

本文的综合场景是这样的：一家约110人的香港内容制作公司，人员分布在制作部门（剪辑师、调色师、动效设计师、制片人）、客户与账户服务、销售、市场，以及财务与行政。两位IT专员支撑着整间公司。两人都出身于后期制作或系统工程背景——他们了解共享存储阵列，了解剪辑团队所依赖的命名规范，明白为什么某台渲染节点老是掉线，也清楚公司名单上哪个客户的交付规格最为苛刻。这份知识不是一家通用服务商能在第一天就复制出来的，而且确实极具价值。

与这份专业工作并存的，是一家110人公司会产生的所有其他事务：笔记本电脑的配置与重装、邮箱与日历问题、覆盖办公桌区与剪辑室的Wi-Fi、终端安全、备份、财务团队使用的记账软件，以及一个从不真正清空的服务台工单队列。而由于制作类工作以截止日期为导向，不会顾及朝九晚六的作息——一个播出时段、一个客户的上线日期、一场必须在周一早上前完成剪辑与交付的周末活动——下班后的告警，最终总会落到当时能联系上的人身上，而实际上，这个人无限期地就是那两位同事中的一位。

真实问题一：两位专员成了所有事情的升级通道

由于两位IT专员是公司唯一的IT职能，他们成了每一类问题的升级通道，而不只是那些真正需要他们专业知识的问题。一位初级制片人的笔记本电脑连不上Wi-Fi，一位销售同事的Outlook莫名要求输入密码，财务部有人打不了印——这些都不需要一个理解媒体存储架构的人来处理，但它们全都落在同样的两个收件箱里，因为根本没有别的队列可以分流。结果是，那些真正依赖对制作架构的机构性了解、具有高价值的差异化工作，被普通工作不断打断——而这类普通工作，本应由一个配置齐全的服务台按部就班地处理。一位调色师因为该处理存储权限问题的专员正在教别人重设密码而干等着，这是公司实际在承担、却从未在任何地方被单独列出来的成本。

真实问题二：任何一人休假都没有真正的替补

一个两人团队没有真正的冗余。当一位专员休年假时，另一位需要同时承担两个人的工作量，而公司习以为常的服务水平，会在整个休假期间悄悄下降。当两人同时无法到岗时——生病、参加会议、家庭紧急事务——公司实际上就没有了IT职能，公司里每个人都心知肚明，无论有没有人说出口。这并非某种极端假设：只有两个人，其中一人无法到岗，是每个月都会发生的事，而不是罕见情况。公司里几乎每一个部门，都在不知不觉间，把"找那两位IT同事"变成了日常运作里的单点故障，而这从来不是任何人主动做出的决定。

真实问题三：补丁管理与监控从来不是任何人的正式职责

真正能预防问题的工作——补丁管理、终端监控、备份验证、审查安全告警——恰恰是那种在工单队列从不清空时最容易被推迟的任务。它几乎从不是任何人明确被指派的职责，而是"等不忙的时候再做"的那类事情，而在一家以截止日期驱动的媒体公司里，"不忙的时候"少之又少。这带来的风险并非纸上谈兵。一台未打补丁的终端、一份数周前就已悄然失败却无人发现的备份、一条因无人有空处理而被搁置三天未读的安全告警——这类缺口，正是一套专门的管理型IT安全服务存在的理由：这不是因为内部专员不懂这些工作，而是因为从未有人把它变成一件真正每天、按计划执行的份内事，不受当天有什么其他事情着火的影响。

真实问题四：升级流程实际上就是"谁回了消息谁处理"

问大多数处在这种情况下的公司，他们真正的事故升级流程是什么，诚实的答案通常是：有人在WhatsApp或Slack上给两位专员中看起来在线的那一位发消息，然后那个人要么自己处理，要么转发出去。没有书面定义什么算紧急，没有正式的值班轮换，也没有任何后备机制——如果平时回消息的那个人因为正埋头赶交付而两个小时没看到消息，就没有别的应对办法。多数时候这套办法能奏效，是因为有两位能干的人在为一个不存在的流程兜底。而它恰恰会在最要命的时刻失效——周一播出时段前深夜的渲染失败，某个周六晚上11点的勒索软件告警——因为"谁回了消息谁处理"，终究不等于一条明确、经过测试的升级路径。

Brocent的观点：真正要问的不是"内部还是外包"

对处在这种情况的公司而言，真正有用的问题不是"IT应该留在内部还是外包出去"。这样提问，答案听起来总像是在"掌控权"与"成本"之间做二选一，而这恰恰忽略了现场真正在发生的事情。更好的问题是：这些工作里，哪些真正属于本公司特有，哪些是每家同类公司早已有成熟解法的通用问题？普通工作——服务台工单、终端补丁、常规监控、标准基础设施的下班后告警——理应交给一个本就全天候运转、也早已建好相应流程的团队。差异化工作——存储架构、交付流程、与特定客户技术要求相关的关系——理应留给搭建它、并理解为何要这样搭建的人。

这种分工只有在被写下来之后才能真正维持。"外部服务商负责基础的部分，我们自己人负责制作相关的部分"这样的口头共识，在启动会议上听起来很合理，但往往几个月内就会开始走样，因为每一张边界模糊的工单，最终都会默认交给最容易联系到的人处理——而这通常就是内部团队，因为他们本就掌握着背景信息。一份明确的纳入/排除清单，定期审视并随环境变化更新，才是防止边界悄悄回滑到本应被解放的那两个人身上的关键。Brocent自2007年以来运营联合管理型安排的经验、以及自2016年在香港设立办公室以来的实践显示，能长期维持下去的安排，靠的是一份写下来的边界，而不是签约当天一个不错的口头默契。

一套联合管理型安排究竟涵盖什么

对这样一家公司而言，一套联合管理型安排通常会把一份明确、书面界定的普通与基础设施工作范围交出去，同时让内部专员继续专注于制作系统，并成为任何触及这些系统的问题所指定的升级对象。

工单队列。 密码重设、账户开通与注销、打印机与外设问题、常规软件支持，以及目前不断打断内部专员的日常服务台工单量，转移到一个拥有自己团队与服务水平的专属队列——这样一位初级制片人的Wi-Fi问题，就不会再耗掉一位调色师一小时的存储权限处理时间。

终端与补丁管理。 企业侧的笔记本电脑与台式机被纳入一套按计划运行的托管补丁与监控周期，独立于制作团队当周正在赶的任何截止日期。这正是两人团队最常掉链子的一环，而这也正是一套托管服务被设计出来永远不会跳过的一环。

监控与下班后告警。 基础设施监控与真正的7×24小时服务台取代了"谁在线就找谁"的非正式做法，代之以真实的值班流程、明确的严重级别模型，以及有文档记录的响应时间——于是一次周六晚间的基础设施告警，有了一个实际的处理机制，而不是取决于恰好谁看了手机。

指名升级至内部专员。 任何触及制作架构的事项——共享存储阵列、剪辑与调色环境、渲染流程、某个客户的特定交付要求——都会按名字升级给内部团队，他们仍是这些系统的权威。服务商不会试图从零学习制作环境，而是通过一套有文档记录的交接流程，把问题路由给已经了解它的人，而不是临时拼凑。

一条被定期审视而非被想当然认定的边界。 纳入/排除清单会按固定节奏重新审视——每当公司新增一套存储平台、开设新的剪辑室，或改变交付流程时——而不是在签约时固定下来后就任其漂移。

两侧真正交汇的地方

公司业务的制作侧与企业侧，并不像上文的划分听上去那样彼此独立，一套联合管理型安排必须考虑到这一点。媒体文件最终需要从共享存储阵列离开，落到某个持久且异地存放的地方；把这套备份与归档层交给规范的管理型IT云服务，尽管它保护的是公司最有价值的资产，本质上仍属于普通工作。销售与财务团队使用的企业网络，与剪辑室所依赖的网络共享着交换机、Wi-Fi、防火墙等物理基础设施，因此一侧的安全与监控，会对另一侧产生直接影响。一份写得好的范围文件，会明确处理这些交汇点，而不是任其落入当下顺手归类的那一类别。

内部两人团队包办一切、完全外包（丧失制作架构知识）、与拥有书面纳入/排除清单的联合管理（Brocent的模式）

• 内部两人团队包办一切 — 对制作架构有深厚、来之不易的了解，剪辑室一旦出问题也能真正快速响应。代价是两位专员大量的每周时间都耗在普通工单上，任何一人休假都没有真正的替补，而补丁管理、监控这类预防性工作，因为活跃队列从不清空而被无限期推迟。
• 完全外包（丧失制作架构知识） — 解决了替补与普通工单的问题，但把在媒体存储、剪辑流程或交付规格上毫无背景的服务商，交托给那些内部团队花了数年才调优好的系统。仅仅是学习曲线，就在业务最经不起意外的截止日期时刻带来了风险，而没有被写下来的机构知识，实际上会随着被裁撤的人一起离开公司。
• 拥有书面纳入/排除清单的联合管理（Brocent的模式） — 普通工单、补丁管理、监控与下班后告警，转移给一个本就为全天候运转而建的服务商，而内部专员则保留制作架构的所有权，成为其指定的升级对象，而不再是一切问题的默认首响者。诚实的权衡在于：这只有在边界被写下来并被定期审视时才成立——一个口头默契会在几个月内悄悄漂回"有事找内部那两位"的老样子。

连接技术架构的两侧

对一家正在权衡这种转变的媒体公司来说，实际的起点通常是技术架构中的企业侧，因为这是每一家管理型IT服务商本就大规模运营的部分。一个7×24小时服务台能吸收目前不断打断内部专员的密码重设、笔记本电脑问题与下班后告警。管理型IT云服务接管备份、归档，以及非制作特有的基础设施，包括企业真正无法承受丢失的媒体资产异地副本。而管理型IT安全服务把补丁管理、终端监控与告警分诊纳入一套固定计划，不再取决于恰好哪位专员当天下午有空。这一切都不需要内部团队交出他们亲手搭建的系统——它需要的，是围绕他们没有搭建的系统画出一条书面边界，并把这些系统交给一个本就为每天、无限期运转而建的团队。

常见问题

联合管理型IT在实践中究竟意味着什么？

它意味着把技术架构拆分成两个书面类别——转交给外部服务商的工作，和留在内部团队的工作——而不是在"完全内部"与"完全外包"之间二选一。在实践中，这通常表现为：服务商接手服务台工单队列、终端补丁、基础设施监控与标准系统的下班后告警，而内部专员保留制作特有系统的所有权，成为任何触及这些系统的问题的指定升级对象。这套安排由一份书面的纳入/排除清单来界定，而不是靠一种笼统的"基础工作对专业工作"的感觉来划分。

联合管理是否意味着我们的IT员工会被取代？

不会——这套安排的设计初衷，恰恰是通过移除目前挤占内部专员时间的普通工作，让他们专注于只有他们能做的事。他们的角色，从每一类工单的默认首响者，转变为制作系统方面的指定权威，拥有一条明确的升级路径通向他们，而不是一个开放式的工单队列。考虑这种转变的公司，通常是想保护专员的时间、减轻其负担，而不是取代他们的知识——在一家媒体公司里，这份知识是花了数年才积累起来的，通常也不是外部服务商能在短时间内复制的。

如何决定哪些交给服务商，哪些留在内部？

起点问题是：某个系统或任务，是否真正属于本公司特有，还是每家规模相近的公司早已有标准解法的问题。密码重设、终端补丁、邮箱管理与基础设施监控，在几乎任何一家百人规模公司都大同小异，理应交给一个专为规模化运营这些工作而建的服务商。共享存储阵列、剪辑与调色环境、渲染流程，以及任何客户特有的交付要求，属于本公司特有，理应留给搭建并调优它们的人。最终结果会被写成一份明确清单，定期审视，而不是留作一种随时间漂移的默契。

内部团队的角色与职业发展会受到什么影响？

他们的角色通常会在范围上收窄，但在专业深度上加深：不再需要在同一个下午里，一边处理密码重设、一边处理存储架构问题，而是把时间用在真正需要他们专业知识的系统上，并成为服务商认可、会向其升级问题的权威。对多数出身后期制作或系统工程背景的专员而言，这其实更接近他们最初想要从事的工作——普通工单的负担，通常是他们默认继承下来的，而不是当初被聘用来做的事。

当事故跨越边界时，由谁负责？

这正是一份书面的纳入/排除清单与升级流程需要在事故发生之前、而非发生过程中就回答清楚的问题。一份结构良好的联合管理协议，会明确写出每一类系统的首响归属，界定问题从服务商所有的基础设施跨越到制作系统时的交接流程，并设定这次交接应有多快完成的预期。事先把边界写清楚，正是防止一次事故最终演变成"这到底该算谁的责任"这场争论的关键。

员工休假或离职时会发生什么？

这是联合管理模式最明显的收益之一。以往每当两位专员中有一人无法到岗，就会停滞或放缓的普通工作，如今由服务商团队持续覆盖，不受谁在休假影响。而如果某位专员离职，过去只存在于那个人脑子里的机构知识，如今风险也随之降低，因为普通业务本就从未真正依赖过他——而真正需要保留的、属于制作特有的知识，也就变成了一个更清晰、范围更小的交接问题，而不是一场全公司范围的手忙脚乱。

联合管理与全面托管相比，定价方式有何不同？

联合管理的定价通常反映的是一个更窄、被明确界定的范围——服务商是就明确纳入范围内的工作类别收费，而非就企业内每一套系统的全面所有权收费——而全面托管的定价则覆盖整个技术架构，包括那些服务商需要花时间从零学习的系统。由于每家企业在普通工作与专业工作之间的分界都不一样，准确的比较方式，是依据这家特定公司的书面范围，而不是一份通用报价单。定价的讨论，应该从纳入/排除清单开始，而不是反过来。

为你的制作架构找到合适的分工点

一家媒体制作公司，不必在"两人团队不堪重负"与"失去让剪辑室正常运转的机构知识"之间二选一。实际的起点是一次诚实的盘点：你的IT团队上周究竟把时间花在了什么上面，其中又有多少真正需要他们赖以立身的那份专业知识？如果答案与上文描述的场景相符，那么有意义的下一步，是就你所使用的存储、交付与制作系统，讨论一条书面边界应该画在哪里——而不是拿一份通用的管理型IT报价单来套用。欢迎联系我们，一起探讨联合管理型分工对你的团队会是什么样子。