【51CTO.com原创稿件】2020年是让我们五味杂陈的一年。从大洋彼岸的同事在去年春节前的一声“年后再见”，到至今仍是“君问归期未有期”;从我春节前将自己微信昵称改为“此心安处是我乡”，到以参加公益直播的形式为武汉加油，作为IT打工人的我经历了不只是工作地点和方式上的巨变。乘着这似乎“慢下来”的一年时间，廉哥进行了一些企业IT治理方面的思考。下面便是我的一些不成熟的小想法……
一直以来，许多企业都秉持着“重建设、轻运维”，“重技术、轻管理”的思想。这直接导致了企业的业务模式能够得到不断的迭代发展，而配套的IT系统与服务则被脱钩不前。这种动与静的失调，往往让企业的IT运维团队疲于捡漏，消极应对。
正如去年业界流行的那句：“居然是2020年的疫情倒逼了企业的数字化转型”。而我们企业的IT团队就乘着上半年无法现场复工的间歇，通过发挥主动能动性，从服务运维的生命周期出发，梳理了当下的技术服务流程与资源，并从如下三个方面进行了一系列的IT治理与运维实践。
作为治理的起点，让我们首先来讨论与业务息息相关的企业IT架构。
架构
随着各类IT技术和应用系统的持续迭代，我们企业的IT基础架构与平台早已逐步形成了多层次、且错综复杂的立体结构。为了避免所谓“学到用时方恨少”的窘境，我们团队在此次疫情远程办公的期间，先后开展了如下活动：
- 整理现有的资料，查看过往的事故记录，进行分组讨论。
- 为了保证条理性和可参照性，在填写具体内容之前，由IT管理层事先定义条目与分类，以便各个职能角色按图索骥。
- 大家分头绘制思维导图，并以“先全面收集，后局部细化”的方式逐步完善。
- 考虑到填表人个人见解的不同，他们可以在“注释和状态”栏中留下原始的录入依据和描述信息。
经历了数月时间，我们基本上能够从如下五个逻辑层面，完成了对当下IT架构“画像”的绘制，以及状态基线的捕获。
- 硬件资源层面，包含：机房与数据中心，各类基础设施与设备等。在详细程度上，我们细化到了设备的品牌、型号、序列号、MAC地址、IP地址、操作系统、固件版本、以及异构特性，同时也按需说明了各种的兼容性、以及相关备件等维度的配套信息。
- 软件服务层面，我们按照目前的主营业务、办公邮件、电话通讯、服务台、用户桌面、文档协作、会议视频、运维工具、以及云端应用等领域进行划分。同时，我们记录下了：应用名称、业务功能、依赖关系、支持提供商、序列号及其使用方式、安装资源的位置和版本等。
- 网络系统层面，包括：内/外部，有/无线网络，路由/交换/网络安全设备，以及各种系统镜像。
- 人员架构层面，我们以人员角色为起点，按照他们具有的访问权限、以及所对应的职能，整理出了树形结构。
- 管理制度层面，包括：基本账号、组群、响应流程、培训文档、操作手册、社交通讯的使用规则、以及对于数据与信息的发布/转发/披露等监控与限制策略等。
除了上述五个“静态”层面，我们还通过请教业务方，归纳出了：系统逻辑框架图、网络架构图、以及应用间数据流转图等“动态”图表关系。据此，我们可以深入获悉到：何种类型的数据将会在逻辑上或物理上被存储在何处，它们在组织/系统间如何进行流动，以及它们受到了何种方式的管理和保护等信息。
通过动静结合的架构整理，我们抽丝剥茧地明确了：在企业层面上，我们有哪些业务;基于现有业务，我们能够提供什么服务;在服务的交付过程中，我们掌控哪些数据;为了保障这些数据，我们需要维护什么样的运行环境，以及需要遵守哪些法律法规。
可以说，有了上述对于IT架构的第一手资料，我们在疫情期间，不但能够有的放矢地开展各项日常运维、问题诊断、以及项目推进等工作，而且及时地发现了某些服务在效率、自动化、以及鲁棒性方面的缺失与不足，为我们在后面将要讨论到的“要保障什么”和“目标是什么”提供了有力的、架构化的关联参考。
服务目录
疫情之前，无论是IT同事之间，还是业务方与IT之间，在请求某些IT服务时，完全可以当面交流，手把手地演示。而在防疫的岁月里，我们只能基于前面梳理出的IT架构，构建了服务目录的“一站式”平台，来展示与发布当下软件产品和应用服务，以便大家来此各取所需。
由于是疫情限制了我们从零开始构建，因此我们只能就地取材，直接利用了既有的SharePoint资源，进行该目录门户的生成。当然，在平台的前期设计和信息源的管理上，我们重点关注了如下方面：
- 事先规定好服务条目的命名规则和一致性的表述方式。例如，针对同一类系统，统一采取：<站点/部门/项目名称>-<系统/服务名称>-<主机名或软件名称>-<型号/版本信息>-<创建YYYMMDD>的格式。
- 事先定义好服务条目的特征项，并预留了可扩展的标识项，以方便访问者通过自定义的查找规则，快速定位所需的服务、获悉完备的信息，进而大幅提高目录的实际使用率。
- 将目录列表的组织结构按照服务或产品的功能、地域等维度，进行分类呈现，并提供了服务的获取入口，以方便查询者按图索骥。
- 通过细粒度地为服务条目预定义访问者的角色、及其对应的权限，实现了对不同的查询与访问群体，开放不同程度的内容视图，并提供了不同维度的资源。
- 在目录的管理上，我们采用“先标记、后删除(即：在被标记的条目会在垃圾箱中保留7天后，再自动删除)”的缓冲策略，最大限度地防止了对于服务条目的误改或误删。同时，我们也配有相应的版本控制，以及针对各项操作的日志记录。
我们花费了两个多月的时间，完成了服务目录平台的初步搭建。而在实际的运行和使用过程中，我们逐渐意识到：应当让平台具有“千人千面”的特点。也就是说，基于AD等角色的不同，用户来此默认看到的，以及查询到的信息，应该更具有身份的强相关性。对此，我们对服务目录进行了迭代升级，将其分拆为如下两套目录结构：
- 业务服务目录：从业务方的视角出发，强调交付的最终效果和服务级别的相关约定(SLA)。在目录的界面上，除了根据访问者的角色，用通俗易懂的文字予以服务阐述之外，还提供了自定义的模糊查询功能，并在下方配有相关服务的在线请求功能。
- 技术服务目录：从IT的视角出发，强调服务本身与支持的组件、配置项、以及相关接口之间的逻辑联系，通过超链接的形式，方便访问者顺藤摸瓜，了解全貌并获取资源。
下面是业务服务目录所涉及到的信息项：
下面是技术服务目录的一个范例：
如今，我们从该门户的后台MAU(月度活跃用户)可知，无论是业务人员，还是IT运维人员，只要他们远程连接进入我们的企业内网，便可实时地查询并获取到精准的可用服务与功能。
小结
常言道：“知己知彼、百战不殆。” 为了搞清楚自己“当前有什么”，我们首先需要从现有的IT架构入手，做一次全面的盘点;然后在此基础上，将这些内容既发布给我们的IT运维小伙伴，又让业务方能够通过服务目录查询并获取到。这便是IT治理的起点，同样也是打造“业务 + IT” 生态链的基础。下一期，我将从可用性、关系管理、以及财务管理三个角度，和您来讨论在“要保障什么”方面的治理实践。提前祝福大家春节快乐，我们年后再见!
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
