|
|
|
|
公众号矩阵

【廉环话】防疫一周年后的IT治理思考 --架构与服务目录

2020年是让我们五味杂陈的一年。从大洋彼岸的同事在去年春节前的一声“年后再见”,到至今仍是“君问归期未有期”;从我春节前将自己微信昵称改为“此心安处是我乡”,到以参加公益直播的形式为武汉加油,作为IT打工人的我经历了不只是工作地点和方式上的巨变。

作者:陈峻来源:51CTO|2021-02-07 10:24

【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】

【编辑推荐】

  1. GitHub超级火!任意爬取,超全开源爬虫工具箱
  2. 实现转型,除了IaaS、PaaS、SaaS,企业更需要BTaaS-- SAP发布业务转型即服务:RISE with SAP
  3. 手把手搭建企业IT实战环境第七季:如何搭建Skype for Business服务器?
  4. 2020年企业级日常架构负载均衡高可用读写分离集群实战演示
  5. 恶意软件分析:利用Speakeasy仿真执行内核态Rootkits
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

6人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

33人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

220人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微