“飞天”，是亲近水的以为神的名字，是可以为人们带来幸福和吉祥之神。“飞天”系统中的各个模块也被赋予了上古诸神的名字：分布式文件系统是开天辟地承载一切的基础之神——盘古，负责任务调度和资源管理模块的是占卜和预测之神——伏羲，从底层上监视和处理导致集群性能下架的集群诊断系统——华佗，负责网络连接模块——夸父，监控系统——神农，集群部署——大禹（现华佗、神农和大禹合为天基）……借诸神之名，映射出的是背后的理想主义色彩。
在众神协作下，“飞天”负责管理数据中心Linux（操作系统）集群的物理资源，控制分布式程序进行，并隐藏下层故障恢复和数据冗余等细节，有效的提供弹性计算和负载均衡的服务。而数千节点规模下，无论是系统的打造还是扩容都面临着众多技术挑战，平台的各个模块在规模性能、高可用性以及可运维性等方面都做了大量的改进和优化。
盘古，在内部架构上采用Master/Chunk Server（主盘/块服务器）结构，Master管理中继数据，Chunker Server负责实际数据读写，通过Client（客户机）对外提供类POSIX（可移植操作系统接口）的专有API（应用程序编程接口）。在集合群扩展到5K（5000）规模后，迎来了新的挑战，主要可分为两个部分。首先是盘古Master IOPS（每秒进行读写操作的字数）问题，因为更大的集群意味着更多的文件和更多的访问，上层应用对存储亿级文件和10亿级文件集群的IOPS是有显著区别的。同时更大规模的集群让快速发展的上层应用看到了更多的可能性，导致更多业务上云，存储更多数据，也间接导致了IOPS的更高需求。另外一个与规模相关的问题就是盘古Master冷启动速度，更多的文件和Chunk（块）数导致更长的冷启动时间，影响集群可用性。伏羲，“飞天”平台的分布式资源调度系统。在5K攻坚中，从设计到实现的每一步都可能存在性能“陷阱”，原因主要在三个方面：规模放大效应，挡节点数增大到数千个时，系统中原本不是瓶颈的与规模化成正比的环节，其影响会被放大；木桶效应，未经优化的那一小部分很可能成为影响系统性能的致命瓶颈；长路径模块依赖，被依赖模块性能的不稳定性最终会影响某个请求处理的性能和稳定性。天基，运维的模式随着5K的到来发生了很大的改变，在解决实际问题的过程中，可以针对各种异常情况，进行故障磁盘管理已经系统异常处理，产品工程师也可以通过它做流程和管理自动化的工作。同时，不必再做几分钟的快速人工修复，而是当故障设备积累到一定量后批量的做替换，大量地节省了人力成本。