k8s 宿主机，ingress详解？
Ingress 是 k8s 资源对象，用于对外暴露服务，该资源对象定义了不同主机名（域名）及 URL 和对应后端 Service（k8s Service）的绑定，根据不同的路径路由 http 和 https 流量
实时监控的运维工具有没有推荐的？
很多开源的，推荐几个：
Zabbix
官方网站：https://www.zabbix.com/
Zabbix是一个基于WEB界面的提供分布式系统监控以及网络监控功能的企业级开源运维平台，也是目前国内互联网用户中使用最广的监控软件，云智慧遇到的85%以上用户在使用Zabbix做监控解决方案。
入门容易、上手简单、功能强大并且开源免费是云智慧对Zabbix的最直观评价。Zabbix易于管理和配置，能生成比较漂亮的数据图，其自动发 现功能大大减轻日常管理的工作量，丰富的数据采集方式和API接口可以让用户灵活进行数据采集，而分布式系统架构可以支持监控更多的设备。理论上，通过 Zabbix提供的插件式架构，可以满足企业的任何需求。
优点：
1. 支持多平台的企业级分布式开源监控软件
2. 安装部署简单，多种数据采集插件灵活集成
3. 功能强大，可实现复杂多条件告警，
4. 自带画图功能，得到的数据可以绘成图形
5. 提供多种API接口，支持调用脚本
6. 出现问题时可自动远程执行命令(需对agent设置执行权限)
缺点：
1. 项目批量修改不方便
2. 入门容易，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发，难度较大;
3. 系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多;并且自定义的项目报警需要自己设置，过程比较繁琐(但是网上的模板比较，也可以使用模板导入的方法);
4. 缺少数据汇总功能，如无法查看一组服务器平均值，需进行二次开发;
5. 数据报表需要特殊二次开发定义;
Prometheus
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。Prometheus目前在开源社区相当活跃。Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。
Prometheus的特点
多维度数据模型。灵活的查询语言。不依赖分布式存储，单个服务器节点是自主的。通过基于HTTP的pull方式采集时序数据。可以通过中间网关进行时序列数据推送。通过服务发现或者静态配置来发现目标服务对象。支持多种多样的图表和界面展示，比如Grafana等。Nagios
官方网站：https://www.nagios.org/
Nagios是一款开源的企业级监控系统，能够实现对系统CPU、磁盘、网络等方面参数的基本系统监控，以及 SMTP，POP3，HTTP，NNTP等各种基本的服务类型。另外通过安装插件和编写监控脚本，用户可以实现应用监控，并针对大量的监控主机和多个对象 部署层次化监控架构。
Nagios最大的特点是其强大的管理中心，尽管其功能是监控服务和主机的，但Nagios自身并不包括这部分功能代码，所有的监控、告警功能都是由相关插件完成的。
用户群：适合复杂IT环境的企业
优点：
1. 出错的服务器、应用和设备会自动重启，自动日志滚动
2. 配置灵活，可以自定义shell脚本，通过分布式监控模式
3. 支持以冗余方式进行主机监控，报警设置多样
4. 命令重新加载配置文件无需打扰Nagios的运行
anglia
官方网站：http://ganglia.info/
Ganglia是加州大学伯克利分校发起的一个开源集群监控项目，设计之初是用于监控数以千计的网络节点。Ganglia是一个跨平台可扩展的，高性能计算系统下的分布式监控系统。它已被广泛移植到各种操作系统和处理器架构上。
优点：
1. 出错的服务器、应用和设备会自动重启，自动日志滚动
2. 配置灵活，可以自定义shell脚本，通过分布式监控模式
3. 支持以冗余方式进行主机监控，报警设置多样
4. 命令重新加载配置文件无需打扰Nagios的运行
缺点：
1. 事件控制台功能很弱，插件易用性差
2. 对性能、流量等指标的处理不给力
3. 看不到历史数据，只能看到报警事件，很难追查故障原因
4. 配置复杂，初学者投入的时间、精力和成本比较大
Zenoss
Zenoss Core是Zenoss的开源版本，其商用版本为ZenossEnterprise。作为企业级智能监控软件，Zenoss Core允许IT管理员依靠单一的WEB控制台来监控网络架构的状态和健康度。Zenoss Core的强大能力来自于深入的列表与配置管理数据库，以发现和管理公司IT环境的各类资产。Zenoss同时提供与CMDB关联的事件和错误管理系统， 以协助提高各类事件和提醒的管理效率。
优点：
1. Zenoss比较出色的地方在于它的Dashboard，可以配置很多portlet
2. 每个用户的界面都是分开管理的，自定义dashboard不会影响其他用户
3. 强大监控功能支持服务器、路由交换、防火墙、存储、数据库、中间件监控
4. 采用基于HBASE的opentsdb存储任意时间段的数据
5. 将状态监控，性能监控，资源管理，良好的报告机制进行有机的整合
缺点：
1. 对资源要求较高，即使只管理少数几台设备，也需要消耗大量硬件及内存等附加资源。
2. 针对windows系统，开源版只提供SNMP，通过WMI检测CPU，Disk，软硬件和性能只在收费版提供。
Open-falcon
Open-falcon是小米运维团队从互联网公司的需求出发，根据多年的运维经验，结合SRE、SA、DEVS的使用经验和反馈，开发的一套面向互联网的企业级开源监控产品。
优点：
1. 自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持
2. 支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
3. 高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
4. 单机支撑200万metric的上报、归档、存储
5. 采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
6. 多维度的数据展示，用户自定义Screen 7. 通过各种插件目前支持Linux、Windows、Mysql、Redis、Memache、RabbitMQ和交换机监控。
缺点：
由于发布时间较短，很多基础的服务监控插件(如Tomcat、apache等)还不支持，很多功能还在不断完善中，另外由于缺少专门的支持，虽然有开放社区，但是解决问题的效率相对较低。
企业需要怎样的容器技术？
这个问题，或许现在发展正热的异构计算技术可以回答。
智能时代，算力提升成为互联网发展特需，在各行各业日趋复杂的大数据和 AI 应用环境下，算力需求爆发式增长。INTEL SVP拉加·库德里表示，要想实现元宇宙级别的用户体验，需要当前的算力要再提升1000倍。如何把种类繁多的异质的计算资源汇集到一个资源池，成为新的算力瓶颈问题。这时，异构计算的概念一出，备受企业和行业期待。2021年7月，工信部发布《新型数据中心发展三年行动计划》明确提出，推动CPU、GPU等异构算力提升，逐步提高自主研发算力的部署比例，推进新型数据中心算力供应多元化。来源于网络异构计算（Heterogeneous Computing）是多元算力的典型。主要是指不同类型的指令集和体系架构的计算单元组成的系统的计算方式，在云数据中心、边缘计算场景等有着广泛应用。跨越标量（CPU）、矢量（GPU）、矩阵（ASIC）、空间（FPGA）的异构计算，如今已经成为企业推动IT基础设施重构的重要力量。其能够将不同架构的运算单元整合到一起进行并行计算，以最适合的专用硬件去做最适合的事如密集计算或外设管理等，从而达到性能和成本的最优化。因此很多企业开始尝试使用异构计算来化解算力瓶颈，挖掘和实现算力增长。通过学习麦肯锡的研究报告所知，全球服务器的平均每日利用率通常最高仅为6%；据 GARTNER统计，全球数据中心利用率不足12%。以上数据都表明，数据中心的服务器成本及资源消耗存在巨大的“浪费”。如果可以把算力资源的综合利用率从6%提升到90%，也就意味着可以立竿见影的增加15倍的宏观算力，同时意味着单位算力成本下降到1/15。在此基础上，叠加高性能的GPU硬件，提升单芯片的计算资源利用率。将进一步突破算力瓶颈，将现有算力的效力放大。然后，资源池化，把孤岛连成一片，再次提升资源利用率。也就是把众多单个芯片的性能，汇集成一个大的算力资源池。VeryCloud就有一个这样的异构算力池，目前设置于江苏常州数据港数据中心中。根据云端数据中心族群架构，通过将各地资源冗余算力统一汇聚到算力池，将GPU、NPU等硬件资源统一池化，通过物理设备抽象化和虚拟化形成可扩展的硬件资源池，并依托虚拟算力的智能切分和调度，可为身在云端生态族群覆盖之处的用户提供任意大小算力。VeryCloud的云端网络南通云算力中心，在建设中也有采取部分硬件云化的方式，形成异构算力之势，为形成云网一体化的数据中心网络群族增添一笔。云端网络南通云算力中心目前在建的上海智慧岛大数据云计算中心，在建成投产后将辐射整个长三角地区，是公司全国区域网络核心节点，也是VeryCloud未来在异构算力方向发展的重要支撑。上海智慧岛大数据云计算中心如今，VeryCloud数据中心建设跟随科技发展方向，逐渐更新、迭代，VeryCloud也朝着异构算力探索更多技术转化，茁壮自身，协助构建以异构为基础的更完整的技术新生态。⭐⭐⭐VeryCloud更多介绍⬇⬇⬇（点击标题下的名称关注我们~）从异构计算窥见VeryCloud数据中心技术新生态或VX搜索“VeryCloud云端网络”关注我们，查看更多~⭐⭐⭐想了解更多云端相关⬇⬇⬇云端网络门户网站⭐⭐⭐欢迎关注云端，了解更多干货⬇⬇⬇VeryCloud云端网络头条主页欢迎点赞，欢迎关注，欢迎探讨~DevOps哪些厂家技术好？
实施DevOps的核心目标是加速团队、企业的IT精益运行，从根本上提升IT的生产效率，加速部门、企业的业务创新能力。
是的，DevOps的优势很明显。那为什么它这么好，但这些年下来实际落地的企业却这么少。除了作者提到的容器、微服务等相关的『环境因素』外，还有哪些内在因素？普元在这方面又有哪些经验和案例？InfoQ就这些问题对普元的主任架构师顾伟进行了采访（文末有嘉宾二维码，扫码加入微信群）。
受访嘉宾简介
顾伟，毕业于东南大学，现任普元公司主任架构师；先后参与和带领了华为BME、中信银行CBJUP、工商银行CTP、中航信RI、阿里云ACE、普元云计算平台、普元The Platform等大型项目的交付；长期致力于IT技术研究、产品设计、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术；对DevOps、自动化运维、微服务架构有着浓厚的兴趣。
InfoQ：请介绍下您的技术背景和目前负责的项目？能否回顾总结并阶段性地介绍下您的技术成长经历？
顾伟：大家好，我是顾伟，专注于DevOps和云计算领域，擅长CI/CD、前端、OSGI、容器等技术，对各类自动化、智能化有着浓厚的兴趣。目前负责普元The Platform云平台产品的设计工作，兼顾DevOps、CaaS、IaaS等外部实施工作。
到目前，我的职业生涯中经历的领域和技术栈比较杂，大体分为以下四个阶段：
06年-07年：以项目实施为主，参与了华为BME项目的多期建设，熟练掌握了包括Java、Web、数据库等基本技能。
07年-10年：主要参与了两款产品研发，一款是基于Ext的所见即所得的UI产品，一款是基于Eclipse插件开发的IDE平台，熟练掌握了主流UI框架和Eclipse的大部分源码。回过头来看，学习优秀框架设计的经历，为今后的架构之路奠定了较好的基础。
10年-12年：以大型企业级平台实施为主，参与了工商银行、中信银行的统一平台项目，也主导过中航信RI等创新项目。在加固已有知识的同时，这段经历使我掌握了诸多企业级中间件（比如IBM MQ、ILOG、BMC CMDB等）的使用和扩展，同时也开始接触了如云计算、大数据领域的新技术。
13年-16年：从与阿里云ACE合作云产品开始，先后历经了普元IaaS（OpenStack），CaaS（Kubernetes + Docker），DevOps领域等产品设计及研发工作。这段时间，拥抱开源并实践于企业级产品中，算是正式走进了企业云计算领域。
InfoQ：您曾经提到过您很关注DevOps和自动化运维。能否简要介绍下您对这两者的理解和未来趋势的看法？DevOps给运维部分带来了哪些变化？
顾伟：在我的理解里，DevOps其实是包含了自动化运维的。只是现在这两种概念都很常见，所以我分开提及的。
大家肯定都能感觉到，DevOps、微服务、容器等概念已经越来越热了。这让我想到了3年前OpenStack的状态，各大社区、创业公司、传统企业，纷纷投入到OpenStack怀抱；而现在，虽然是有一些公司存活下来了，但总的来看谁也没赚到多少钱，也没有哪家公司如预想般把VMware给替代了。过热的后果是反而把市场秩序给弄得一团糟，产品低价竞争，人员漫天要价。
我觉得现在的DevOps也到了这个岔路口，有很多公司在热炒DevOps的概念，并纷纷宣布转型成功；而从实际市场、尤其企业市场的反馈来看，客户对此的评价几乎众口一词：“DevOps很好，但我们很难做到”。
究其原因，最缺乏的是DevOps方案提供公司真正到深入到企业里面，沉下心来，结合实际情况进行实施实践，从而帮助客户切实地做到横向协作打通、纵向工具链打通。所以我觉得，市场到今年底前还是会充斥着很多概念炒作；但从明年开始，大家会逐步看到，这个领域中真正的脱颖而出的，将会是那些已经将DevOps实际落地的企业和服务商。
DevOps给运维带来的变化，主要体现在运维工具的打通，但是单单从这个角度看影响并不很明显。如果能够从企业、部门、团队多维角度结合来看，才能发现DevOps独特的地方。
DevOps本质上是一个持续优化的过程，一般需要从组织、技术、流程三个维度考虑，目标是加速IT的精益运营。 DevOps推崇的是让开发、测试、运维友好协作，倡导大家都能为各自的上下游提供便利，形成演进回环，有效的支撑业务创新。
InfoQ：你提到，DevOps很好，但也很难落地。你认为难点在哪里？如果说要突破这些挑战，你认为团队负责人应该重点从哪些方面入手？
顾伟：我觉得DevOps最大的难点并不是所谓的文化或组织（因为这个不是说改变或打破就能改变或打破的），而是各家公司的流程和工具都是有差异的，每家都会有自己的特色与特殊部分，很难有所谓的通用产品能解决所有问题。
举个代码库工具使用方式的例子，之前在我们微信群里还单独拿出来讨论的，有的企业是主干开发、分支release；有的企业是分支开发、分支release，接着再往下细，都是分支开发并release的企业，同一个产品版本，有的是开发环境、测试环境、生产环境对应的分支物理上是不同的，也有开发测试环境相同、生产环境不同的，还有从开发到最终上线就一个分支的。而且每家做法都有很充分的理由……
想突破这种问题，对于一个团队负责人来说，要能在一定的条件下，有效组织团队、逐步优化流程。这里说的“一定的条件”涉及很多方面，比如不要试图按理想情况去打通部门，这是永远不可能的，再比如想让团队每个人都有一样的高度、理解力、责任感也是很难实现的。所以对于一个团队负责人来说，想实施好DevOps，需要理清现状，统一概念模型，制定阶段性目标，激发团队热情，有效规避风险；而不是一上来就是要用什么技术，要有多好的理念之类。
InfoQ：你如何看不可变基础设施？
顾伟：看到这个问题，首先想吐吐槽：初次听到不可变的基础设施时，我当时不知道为什么，还想起了另外一个概念：基础设施即代码，虽然这两者没有特别的强关联，但第一感觉就是，现在市场上很喜欢拿基础设施来说事。
我以前做过IaaS、PaaS，也参与过运维工作，基础设施在我的理解里是一个底层、重、固化的东西。随着一切皆服务、一切皆代码、无状态这些概念起来，让我觉得市场上的任何词，都可以变成“怎么说都有理”的理念。
回归正题，我认为要像不可变的基础设施的目标前行，有两点比较重要：
从使用者的角度来看，基础设施最好是无差异无感知的，所谓的无差异或无感知是说无论下面是什么样的异构硬件、不同系统等，对上层业务的服务提供方式都是统一的；
从提供者的角度来看，基础设施从建立之初就不要再变更，只有新建与替换，粒度很重要，这也是很多人甚至会提到消除SSH的想法的原因。
对于不可变基础设施的未来，我认为是个长期的目标。随着容器、DevOps能力的逐步落地，给了这个目标一个可实现路径，但真的要做到完全不变，我觉得是很难的，因为生态还没有起来，很多层的能力或接口还没有统一和规范，差异化永远是不可变的最大拦路虎。
InfoQ：这两天又有人提出了OpsDev的概念，你怎么看？
顾伟：这个我之前也看到了，看到第一句解释后我就没再看下去，因为从来没有人说过DevOps到底是Dev2Ops还是Ops2Dev，为什么？因为无论是Dev还是Ops，都应该将对方视为可标准的对象，同时为对方提供足够可规范的便捷（主动的尝试着去适应对方），这本来就不是一个单向的过程。
所以我认为无论是叫DevOps，还是叫OpsDev，大家的目标都是一样的，切勿认为词语上的谁先谁后，就意味着谁主动谁被动。在不失规范与流程的前提下，打通上下游、双向协作才是DevOps的真谛。
InfoQ：您即将在CNUTCon全球容器技术大会上和我们分享《基于微服务架构的容器云之实践》，可否先大概介绍下你们的容器云？
顾伟：其实普元的主要目标是落地DevOps，在技术实现上，只是底层默认使用了CaaS作为支撑（当然平台也兼容IaaS）。平台在原有的基础能力之上，实现了容器+微服务的部分，并不断版本迭代演变至今。第一个版本花费约半年多时间。这次，为了契合容器大会主题，我选择了底层CaaS部分的实践进行分享。
目前我们的容器云既可以运行于私有云（OpenStack、VMware），也可以支持在公有云（阿里云）上运行。平台以微服务架构为支撑，使用了Kubernetes + Docker的组合，以CoreOS、Flannel、SkyDNS等作为支撑选件，集成了包括MySQL、Redis、GIT、Nexus、Jenkins、Docker Registry等基础服务，形成了一款用于支撑企业DevOps的容器云平台。平台最终架构图（含DevOps能力）如下：
InfoQ：这套容器+微服务实现的DevOps方案，您认为哪类行业的企业可以借鉴参考？传统企业可以在哪种情况下，开展怎样的尝试？又该如何拆分传统应用？
顾伟：这套方案相对来说，比较适合有一定规模的企业或互联网公司。因为如果团队较小、业务较简单（比如只有极少数量的App），那首要的问题还不在精益化上，通过人来做管理配置，也不会特别复杂。
对于传统企业来说，我的建议是尝试需要首先从这两方面开始：
持续发布能力：这是打通开发测试与运维的最佳着手点，也是业界目前方案成熟度较好的模块。
自服务能力：自助和自动，是打通上下游、提升运营效率的有效手段，自服务能力强调的正是这一点。
至于提及微服务化是如何进行单块应用拆分，我觉得是这之后的事情：没有配套的运营支撑平台，何谈微服务架构。
InfoQ：您提到过目前的这个方案在13年的时候普元就有提出过。当年是在什么样的情况下想到的呢？为什么当时没有落地这样的想法？
顾伟：翻翻历史，这个点子是13年的时候，我们董事长刘亚东先生提出的，当时他指出：“数字化未来会将企业每个人、每台机器都变成一个节点，企业信息平台需要具备打通供应链、资金链、物流链、销售链、服务链等能力，这就需要企业在未来竞争中找到自己的位置，就必须用数字化企业云平台”。
至于为什么当时没有落实下来？我个人觉得，毕竟当时董事长提出的无论数字化、还是连接一切等概念还比较前沿，我们团队的积累和认知不是很够等种种原因吧，没有在当时真正执行起来。现在回过头来看，算是在给当时的愿景圆梦吧！
InfoQ：为什么微服务的架构要采用容器做默认承载？如果不采用容器技术，您认为微服务化会面临怎样的难题？除了微服务化架构的实现，普元还有在其他情况下使用过容器技术吗?
顾伟：首先我的观点是，微服务架构和容器没有任何关系，大家也可去翻一翻Martin Flower的文章。那为什么现在大家看到的文章中，提到微服务就会提容器，或者提DevOps，本质上是因为以下两点：
其实很多公司的现状是仅仅实现了容器管理，但是又想接下来向微服务化靠拢，于是就出现了强关联的概念。
事实上，现在也确实存在很多企业把两者结合在一起使用。无意中让大家误会了两者的关系。
但是这只是说明了两者相伴相生的现象，并不意味着强因果关系。
容器的优势在于：轻量化、原子化、可移植性、快速集成等，而这与微服务所倡导的松耦合、高内聚有着异曲同工之处。 在实际使用中，往往容器+微服务确实可发挥 1+1>2 的功效。
容器可以作为默认承载，但要支撑企业级系统，不能只有默认承载。因为容器的相关技术完备性现在还不足以完全支撑业务，像容器的存储方案、有状态服务方案这些生态技术还并不太成熟。
如果不采用容器技术，传统VM技术、或者说IaaS，甚至纯物理机架构，照样可以支撑微服务架构，只是在管理上稍微复杂些。在普元，我们是通过统一的环境管理（内部系统叫SEM），来屏蔽底层基础设施差异的，大家可参考我们异构环境下的统一概念模型：
目前容器技术的使用主要在这款数字化云平台里，其他地方用的较少，只在一些客户试点项目中有过尝试。
InfoQ：相比较历史系统的DevOps，基于容器技术的DevOps具有哪些特点和优势，适用于哪些情况？您是否认同“容器改变DevOps”这种观点？
顾伟：DevOps有时会让人觉得很遥远，也有很多企业会觉得先做到自动化运维就足够了，大家对于这个概念其实褒贬不一。技术方案上，也是层出不穷，近期看到一些微信群、公开课、沙龙在讨论DevOps实现：有用容器的；有基于Puppet、SaltStack延伸的；还有一些生于Cloud Foundry、OpenShift这些传统PaaS之上。换而言之，DevOps其实并不局限于任何具体技术，只是容器技术在实现DevOps时有一定的优势：
灵活：DevOps的一项重要工作是“编排”工具链，要求能够对“原子活动”进行快速串接，而容器本身对于原子化及编排能力就有很好的支撑。
集约：DevOps的一大价值是资源集约管理，容器相对于传统VM，在资源利用上就有很大优势，其资源长短生命周期皆宜的特征，对于像开发测试云这样的需求尤其合适。
标准：以镜像为粒度的管理模式，相比于零散脚本、多变介质、各种小工具等规范度不高的传统开发运维，给了实施者一定的标准。伴随着配置、服务状态等生态技术的补充，容器实施DevOps的方案会变得更完善。
您提到的“容器改变DevOps”说法，我认为偏绝对；我更倾向于“容器让DevOps更容易”。
InfoQ：对于容器的运维，您认为有哪些需要特别注意的问题呢？能否详细谈谈的双模架构（模态1：传统技术，模态2：容器技术）的自动化运维？
顾伟： 我认为对于容器本身的运维，其实和传统的运维没有太大差别。要说容器运维有什么特别注意点，我觉的下面大家可关注以下3点：
选择一个合适的框架，不要什么都自己研发：目前业界很好的框架并不多，K8S、Mesos、Docker本身的一些，选择您觉得和你们理念最一致的，作为你的基础框架。
避免惯性思维：很多做过传统运维的同学，在遇到容器时，第一想法还是用既有知识和习惯管理，所以大家会发现，现在很多企业把容器当VM用，或者宿主系统一定要XXX，这个往往束缚了容器运维的优势。
要向上抽象：毕竟容器还不能完全替换企业既有，那资源、中间件、应用的运维和容器的运维是不是可以统一，这就要求在运维角度抽象一层模型，便于后续的一体化运营平台的建设。
对于双模架构的自动化运维，核心问题就在于能否抽象出一套兼容的模型，屏蔽各种异构差异化，可从以下四个方面考虑：
环境：主机、存储、网络、容器的差异化。
配置：应用配置与环境配置，动态配置与静态配置。
仓库：三方仓库、部署包仓库、镜像仓库等。
流程：编译流程、部署流程、故障流程等。
InfoQ：您说这个点子成功在于：”市场上的客户反馈和内部的能力驱动”。能否将这两个方面进行详细的展开论述？
顾伟：不仅仅是这个点子，我认为任何点子的成功都离不开这两方面：
客户反馈：反馈的核心价值在于驱动产品向正确的方向演进，比如小米，从设计之初就笼络了一群发烧友，请他们来提建议，帮助做设计。换个时髦的词叫MVP，意思和快速推出试错试对，这与管理学中的PDCA质量环有着想通的理念。我们要做大设计小版本，进而通过Inside-out & Out-inside的有效配合，基于反馈快速迭代，才能推出符合市场需求的产品。
能力驱动：这个也可以讲成康威定律，我更倾向于称之为康威定律+，团队一定程度上决定了业务架构，拥有一个全栈的团队，对于一些创新类点子有着非常重要的作用。在一个点子形成之初，原型、场景、计划、设计、迭代模式、技术预研等，环环相扣，任何决定都对后期的发展有着的重要影响，所以我一直认为：有什么样的基因，做什么类型的事情。有什么能力的团队，做什么规模的事情。
InfoQ：最后一个问题：技术变革日新月异的今天，对于立志在技术领域中长久发展的年轻人，您有什么建议和忠告？
顾伟：忠告不敢当，结合我带新人的经验谈谈一些想法吧。
首先，技术是学不完的，以前是，现在更是。对于刚开始工作的同学，在精不在广。任何有一定规模的技术框架，都有很多值得深入学习的地方，别人为何这么设计，相比同类产品有什么优势。多思考，多总结。不要一味的只管调试代码，fix bug……
学技术之外，也要学做人。技术再牛，如果无法融入团队，那还是没用。此外，新同学必须要有自主性。现在很多新同学有个通病，遇到问题就问导师。不是说不能问，关键在于问之前你有没有真正的花精力尝试过，或者试着问题缩小到一定范围，不能说一遇到个坎就找人帮忙，会让团队的人觉得事情交给你很不放心。
最后就是执行力很重要。很多同学都会定目标定计划，但却很少有人制定对应的check计划，好像这都是部门经理的事情。说白了就是缺乏自我管理能力。现在的人确实受打扰太多，但这不是执行不力的借口。建议大家制定计划时，要短期不要长期，要实践而不是停留在概念。
Windows的服务器好用？
面对这个问题，一些人尤其是互联网相关从业人员，会觉得服务器系统当然选择Linux更好啊，我们公司的服务器就是Linux系统的；但同样也有一些人，会觉得Windows操作系统操作便捷，还有微软作为技术保证。
先说我个人的观点，Windows和Linux系统在服务器上的表现都很好，具体选择哪一个，还要看你的需求到底是什么了。
至于原因呢？还是基于同样的原则，不要以自己看到的主观感受来判断，而是通过客观的数据来说明这个问题。
Linux vs Windows市场占有率对比特别声明：由于通过外部进行数据统计仅能获取暴露在外的服务器信息，因此该数据仅限于统计网站服务器。
首先，介绍一个网站工具，netcraft（也可直接输入网址：https://searchdns.netcraft.com/）。
在输入框中输入目标网站，可以通过列表看到图中箭头所指的OS列信息（若想看具体信息，可以关注site report列）。如果我可以遍历这个世界上所有的网站，那么我就可以获取一份统计表，对应就是Linux和Windows的市场占比。
为了方便起见，我这里就不写爬虫进行爬取，而是直接使用现成的。w3techs，是一个广泛而可靠的网络技术调查网站（这个网站上的数据会按照天进行更新，还是很有权威性和实时性的），在这个网站上找到了我们希望得到的统计结果，具体信息如下图所示。
https://w3techs.com/technologies/comparison/os-linux,os-windows
从图中可以看到，除去unknown的服务器外，Linux占比35.0%，Windows占比29.2%。
对网站进行进一步细分，细分的依据是按照该网站的排名，可以看到一个有趣的现象。越是顶尖的网站，服务器使用Windows的占比就越高，例如，针对Top1000的网站，其中Windows占比52.9%，而Linux仅占比34.3%。
换句话说，越是牛逼的网站越是倾向于使用Windows，是不是跟各位的认知产生了一定的偏差？
Linux vs Windows市场占有率发展情况还是根据w3techs网站的最新数据显示，Linux的市场占有率有较大的下滑趋势。
也许这里就会更加疑惑，为什么服务器选择Windows操作系统不仅不是非主流，而且还有如此大的市场占有率，那么所谓的Windows系统不稳定的问题又是如何呢？
上面这个图中显示的是Linux和Windows系统在人气和流量方面的情况。其中横坐标为使用者的数量，即人气；纵坐标为服务的流量。
那么又有一个现象出现了，Windows操作系统比起Linux系统，更多的被使用在高流量的网站上。
现在回到最开始的那个问题，Windows和Linux服务器哪个好？还有那么绝对的答案吗？这个问题也逐步的变成了，在企业级服务器应用场景下，Linux和Windows服务器各有什么优势。
Linux与Windows的核心区别总的来说，Linux与Windows的核心区别：
一个开源生态下依赖众多开发者所维系的一种操作系统
VS
一个利益驱动下依赖企业进行维护迭代的一种操作系统
因为生态环境，造就了两个操作系统最大的差别，深刻理解了这一点，就会明白为何有人选择Linux，而也有人选择Windows，只是大家做选择时的核心诉求不一致而已。
举例说明一下具体情况：
小张，作为一个处于创业初期的公司合伙人。现在有业务需求，需要搭建一个公司的网站，这时业务还很简单，两者都能满足诉求，因此便宜成为了一个关键因素。由于Windows操作系统是需要付费的，而Linux作为一种开源系统，选择后者可以在创业初期节省一笔开支，因此小张兴高采烈的选择了后者。
小王，作为一个大型互联网公司的技术负责人。现在同样有业务需求，需要开发一个底层框架，用于处理大量并发数据，需要改框架支持GPL协议，后续在GitHub上进行开源，给业界提供解决方案标准，那么在开源生态下成长起来的Linux系统也是小王的不二选择。
小李，作为一个国有银行的IT部门负责人。由于银行的属性，在采购合同签署过程中需要有一家乙方公司对提供的服务保证稳定，同时提供及时的售后技术支持，这时放弃Linux而选择Windows，就是不依靠都叫不上名字的相关社区开发者，而是依赖微软显得更加靠谱。
这个时候，再回过头去看之前的统计数据，对于数据本身所表现出来的问题，还会觉得意外吗？
Linux与Windows的优劣对比目前看上去确实有一定的差别，例如很多人所说的安全性，一个公开的依靠世界各地顶尖开发者维护的系统，与一个闭源的由垄断巨头所维护的系统，看似确实前者安全性更好，但是也不要忽略利益的趋势，既然微软作为一个企业，那么赚钱就是其最大化体现，为了更好的赚钱，提供更好的服务也许是最简单的途径。
Windows和Linux的优劣其实网上一搜一大堆，但是我要说的是，随着时间的发展，Linux会越来越Windows，而Windows也越来越Linux，竞品的出现本身就会按照时间的发展而取长补短。同样按照市占率和后续发展，支持Linux的同时支持Windows也会越来越重要。
