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