来源：互联网作者：编辑点击:
导言
北京市政交通一卡通有限公司（以下简称“一卡通”）成立于2000年，业务范围包括交通智能卡的制作、发售、应用和结算业务。2015年经北京市交通委授权建设、经营京津冀区域中心，截至2022年初，一卡通服务范围已经覆盖全国。而在业务方向上，一卡通在不断优化公共出行体验的同时还包含智慧运营解决方案以及大数据服务等相关业务。
【图1】一卡通卡片制作环节
随着移动支付在交通领域的普及，互联网用户量、并发量都出现爆发式增长，敏态业务的增多以及双活场景都对一卡通技术部保障业务的连续性、系统可靠性、网络质量提出了更高的要求。另外，在常规C端业务之外，技术部还承担了公众民生相关的互联网运营业务，对B端专线可视化监控的要求较高。过去技术部通过流量监控平台的搭建基本实现了对传统业务的可视化监控，而对云端业务及B端专线的监控能力还存在监控盲区，本次我们采访了一卡通技术部负责人李志宇，请他为我们介绍如何通过与智维数据的进一步合作，满足“两云三中心”混合云流量监控场景，以及如何从基础设施运维到价值输出，实现对外IT运维服务，为一卡通双向业务连续性提供较全面的监控视角及多维分析指标支撑。
1．99.96系统可靠性敏态与稳态都要确保稳定持续
记者：一卡通的运维特点跟其他的行业会不太一样吗？
李志宇：一卡通是典型的混合云场景，既有敏态业务也有稳态业务。我们与机构客户端之间的交互，例如与银行清分、结算属于稳态业务。一卡通还有海量互联网C端客户，尤其是APP端的业务场景都是敏态业务。
这几年敏态业务增长非常迅猛，我们的服务对象是公众，高频、高并发、小额支付是我们的业务特点，一卡通对网络体验的要求要高于普通的互联网公司，每一个使用一卡通APP的用户，或者是每一个安卓一卡通、苹果一卡通的用户，只要出现交易的时延，用户体验是很直观的，作为技术部门我们希望能带给大众最快速、稳定、便捷的使用体验。
记者：请简单介绍您所在团队主要的运维的目标。
李志宇：目前技术部已经达到99.96系统可靠性的指标，就数据中心业务连续性来讲也有相应指标支撑，比如RPO、RTO。实际上现在我们可以做到敏态业务数据丢失基本趋近于0，为保障任何一笔交付数据不丢失，我们做了一些双活的场景；然后从系统切换来讲，如果一旦一个中心出问题或者是网络中断，需要达到至少分钟级切换。针对稳态这一块数据也是无丢失的，整个切换时间要求在30分钟以内。这两个维度的指标是一卡通当前网络系统运维的核心指标。
记者：有哪些运维工作难点？为什么会考虑运用新的流量分析工具？
李志宇：以前一卡通只有线下数据中心，这几年建立了多源多活的场景，即“两云三中心”。C端用户的网络时延导致了业务不可用，或者是用户体验不好，之前运维人员第一时间从监控上是无法感知到的，这是第一个挑战；第二个挑战是一卡通除了公众所熟知的智慧交通业务之外，我们还承担了一些公众类民生服务类相关的网络运营，这些B端业务专线数量有数十条，实现B端业务流量可视化也是非常重要的。以前无论是C端还是B端从用户反馈问题到运维人员处理，因为当时的监控工具无法追溯问题原因，所以信息是滞后的。要应对这两方面的挑战，让我们最后采用了智维数据的解决方案，既能针对互联网敏态业务，又能监控B端业务流量，实现混合云流量可视化监控。
2．运维能力提升助力业务范围拓展，IT运营能力输出，向利润中心转化
场景1、广域网链路监控
记者：一卡通在互联网端遇到的网络性能问题有哪些？如何解决这类问题？
李志宇：运维团队经常利用nCompass的广域网视图实时监控有哪些链路存在质量不佳问题。比如，曾经有移动端用户反馈使用一卡通APP无法完成交易处理。之前需要运维团队从手机端广域网链路再到数据中心分阶段手工抓包分析，给运维团队造成较大工作负担。而采用了nCompass之后，通过广域网视图能够清晰看到所有链路的各项指标，有助于支撑我们复杂业务的问题定位。
【图2】广域网TOP 监控视图
这些指标包含带宽的利用率、时延等。正常情况下广域网链路的时延是5毫秒或者是10毫秒，如果突增到30以上了，代表异常。带宽利用率正常的峰值在20～30，一些业务活动时会达到70。如果在没有活动的情况下，突增到70以上，此时虽然业务还未受到影响，但也属于异常情况，运维人员可根据这些指标情况进行预先处置，规避未来可能发生的系统风险。
场景2、公有云、混合云监控
记者：一卡通现在已经向公有云、混合云的架构演进了，现在对网络运维的要求有变化吗？
李志宇：从整个运维或者是建设这一块来讲，我们遵循的是一个“三同步”原则：统一规划、统一建设、统一运维。因此我们一直在寻求云上应用和线下数据中心应用的一体化监控方案。现在在公有云上部署nCompass-Cloud云探针用于采集虚拟机的网络流量，部署nCompass流量监控平台用于分析和存储云探针采集的网络流量。实现了云端网络流量数据的采集、分析和存储，并接入线下统一管理平台。统一监控平台的好处是多云监控统一纳管、统一展现。现在一卡通的云端业务如网站、非交易类互联网业务、测试业务等都实现了可视化监控，为我们之后实现端到端全景监控打下了良好基础。
场景3、重点业务监控（支付类）
记者：一卡通的业务有哪些？网络运维是如何为这些业务端服务的？流量监控又在里面扮演一个什么样的角色？
李志宇：一卡通的业务类型有支付业务、民生业务、结算业务等。另外我们也承担整个京津冀交通互联互通区域中心的运营，业务应用超过上百套。所以无论是全局性的流量监控还是故障定位以及故障回溯，对于网络运维来讲都非常重要，比如支付业务。
【图3】联机打卡监控视图
针对支付业务，前面我们也提到这类业务的特点是小额度、高频率、高并发，运维团队要保障在整个支付环节中数据不能丢失，因此我们对一些重点场景定制了流量监控视图。以联机签到监控视图为例，每天早晨无论是地铁的闸机，还是公交车上的车载机，还是公交网点的POS机，这些终端跟一卡通后台系统是做联机签到的。整个签到过程大概在1—5分钟不等，签到过程中会产生一个瞬时的高并发，可能同时有数千台的终端设备要和后台进行认证。这个过程中有的网络是依托于专线连接，有些是通过无线物联网通讯，由于整个业务环节是非常复杂的，连接的机构与系统繁杂，此时对于监控签到流转中的各层数据就非常重要。一旦出现打卡失败，无法联机等问题，通过人工排查几乎难以实现，此时我们通过签到监控视图就可以快速定位问题处于什么范围，从而提升故障处置效率。
场景4、ToB业务专线监控
记者：一卡通目前承接的ToB类业务包括哪些？流量监控在这些业务运营支撑中起到什么作用？
李志宇：一卡通除了大家熟知的To C业务外，也承接了服务民生的业务，包括养老助残、见义勇为卡、老年人卡、公园年票卡等。我们技术部是作为解决方案提供商或者是云服务商的角色，是一种IT服务输出。原有一卡通的业务在“两云三中心”运行，但是新承接的民生业务未来也需要在其中运行。
【图4】专线链路监控
一卡通的B端业务都是通过点对点的专线连接，运维人员能通过流量监控平台自主查看网络层的线路质量，也能监控到应用层的响应情况，有无异常延时等。例如曾有客户反馈在网点做业务超时、异常，我们通过监控查看线路容量、带宽使用率、业务占比、线路质量管理、丢包、时延等均在正常范围，虽然业务质量监控业务带宽占比正常，但是业务质量指标却异常，因此很快与应用部门确认问题所在，并予以解决。
一卡通现在正在构建的IaaS、PaaS、SaaS云平台除了支撑自有业务外，也包含以上这些To B业务，运维实力的保障让一卡通可以对接这些IT运营服务类项目，也赋能技术部从成本中心向利润中心去转型。这些都要求我们之后要更进一步实现端到端的全景监控，保障双向业务运维持续、高效。
3、轻应用，云服务一卡通的智能运维下一站
记者：对未来一卡通的智能运维发展有什么计划？
李志宇：无论是私有云还是公有云，需要形成一体化的网络、一体化的安全，不仅仅关注南北向的流量，也关注东西向的流量。运维场景可以是多维度的监控、故障处置、运营分析、资源预测，我们希望下一步能与智维数据合作形成整体的解决方案。在适配云这一方面要求所有的IT服务模式更加灵活。特别是我们的业务属性中还有相当一部分To B业务，我们也初步完成了从对内运营到对外服务的能力升级，要适配一卡通B端业务不断拓展的场景，以及C端互联网敏态业务不断上升的需求，未来在系统可靠性和健壮性的基础上，轻应用、云服务是我们探索的技术方向和目标。
