加入星计划,您可以享受以下权益:

  • 创作内容快速变现
  • 行业影响力扩散
  • 作品版权保护
  • 300W+ 专业用户
  • 1.5W+ 优质创作者
  • 5000+ 长期合作伙伴
立即加入
  • 正文
  • 推荐器件
  • 相关推荐
  • 电子产业图谱
申请入驻 产业图谱

我们对腾讯「战疫」实情一无所知

2020/03/04
126
阅读需 31 分钟
加入交流群
扫码加入
获取工程师必备礼包
参与热点资讯讨论

很多人生很重要的决定,似乎都是在一瞬间做的,对于一家公司来说,同样也是。

1 月 20 日,农历腊月 26,距离腾讯放假还有三天时间。腾讯健康的十多位产品、研发、运营、商务的员工围坐在一张会议桌上,在场的人面带紧张。

这一天,钟南山院士正式确认了新冠肺炎“人传人”的消息。腾讯公司总办高管们以及腾讯副总裁丁珂(分管医疗业务)在微信群里询问 Kyler,“疫情发生了,腾讯该做些什么”。

作为腾讯健康小程序的总指挥官,腾讯健康副总裁 Kyler 觉得这件事情不能等了,疫情是目前医疗健康团队的最高优先级。

那场会议整整持续了六个小时,会上谈论了哪些细节,已经不得而知。

人们所能知道的是,那天之后,腾讯健康像被摁了快进键:

1 月 20 日,产品、研发讨论会,项目正式启动;

1 月 21 日晚上 8 点半,产品设计图出炉;

1 月 22 日早上 6 点,第一个 H5 版本开发完成;

1 月 22 日早上 8 点,第一个版本正式上线。

4 天后,1 月 26 日,微信支付页正式上线医疗健康,第九个面向十几亿用户的全国(全球)入口被填满。微信多年没有的大动作,在疫情之下不到一周被敲定和执行。一个囊括了疫情疫况、权威科普、发热门诊地图在内的全套疫情工具出现在每个人微信里。

再过一周,这款小程序日活跃用户超过了 3000 万,一跃成为移动医疗服务领域第一名。

腾讯健康这艘还没有正式下水的船,在疫情的暴风雨里,被猛然推向了大海。而腾讯基于社交的产品、技术基因,也在全新的医疗行业迎来了一次大考。

两个字的锦囊
事情在一开始,并没有那么顺利。

做一个什么样的产品?在 Kyler 的预想中,腾讯健康的疫情产品不应该是一个个散碎的功能,而应该形成一个完整的线上链条,层层分解用户的需求,逐层收敛,帮助用户规避恐慌、自我防护的同时,也最大可能地帮助医院形成精准收治,避免不必要的交叉感染,节约医疗资源。

但到底要怎么做,具体提供什么功能?这个问题就难住了,很多人是第一次经历这样的突发疫情。

20 号会议结束之后,腾讯医疗健康应用产品中心总经理何波写了一份名为《我回忆了一下当年非典》的文档发给了产品团队,这份文档不长,只有 600 多字,但是却成为了产品团队的重要说明书。

她列了一些疫情中会被关注的需求:

疫情实时数据,必须保证与国家卫健委同步,播报不追求抢、快,而追求准确、同步。

有效防护措施,注意疫情的演变,防护措施也会演变升级。

官方确认的收治医院信息、综合医院发热门诊的信息、被隔离场所信息。

用户自查、互联网在线问诊会成为刚需

……

这些需求就像是一个“漏斗”,层层筛选用户的需求。拿着这份说明书,产品团队开始动手。

互联网人要承认的一件事是,腾讯有全中国最好的一批产品经理,而腾讯健康产品负责人 Snail 和产品经理小敏也是其中两位。

经历了那个长达 6 个小时会议、看过何波说明书的小敏,之后画下了腾讯医疗健康 1.0 版本的产品设计图。

在很长一段时间里,小敏每天只睡 3、4 个小时,还有过持续高强度工作 42 小时的纪录。

她说,疫情发生的那几天,自己满脑子想的事情就是“需求”:早上固定时间对需求,白天不停地发版本,晚上就是写需求、想需求。

让她感触非常深的一点是:“作为一个女生,我从来没有哪一天敢不洗脸就到公司,那段时间真顾不上了。好在大家都要带口罩,否则的话,真的是没脸见人。”

然而,让小敏过意不去的是自己的父母。因为,这是她长这么大以来,第一次没有给父母拜年。

她记得很清楚,年三十的那一天,很多同事是在公司一起吃的年夜饭,但是为了不聚集,大家都是从食堂打完饭之后,自己分开单独吃。

 

(腾讯医疗健康团队的年夜饭)

差点就跪了
万事开头难。发热门诊地图是腾讯健康团队从零开始做的一个功能,也是最崩溃的事情。

疫情发生后,具有疑似可能的发热病人需要到专门的发热门诊,但并不是每个医院都有发热门诊,患者常常跑了很远,白白耽误时间,准确的发热门诊地图成为一个刚需。

要做发热门诊地图,就要有定点医院的信息,权威来源只能是各地卫健委来发布。

然而,信息发布的形式并不统一。一些地方的卫健委在发布定点门诊列表的时候,是纯图片的形式,团队只能在后台手动输入字段。

腾讯健康产品负责人 Snail 说,“做运营的同事和产品的同事一下子就跪了,说这要搞到什么时候。”

没办法,既然决定了要做,只能硬着头皮上。产品团队决定从离自己最近的地方———广东做起。

腾讯健康一位 95 后的商务文静找了广州市疾控中心合作,做出了广州版发热门诊地图。疾控中心觉得这件事非常有用,甚至把发热门诊的小程序二维码打印出来,贴到广州所有的地铁站和其他需要宣传的地方。

在这之后,国家卫健委也提出合作需求。这个消息让 Snail 的团队大为振奋,但是,看到全国 14000 家这个数据时,他倒吸了一口气。

“我们希望能在两天内就上线这个功能。但是,1 万多家太多了。我们要把每个医院的地址和具体坐标拎出来,再和地图团队商量加到地图里,最后还要加上导航的功能。”

Snail 愁得不行,因为数据清洗是一件纯靠人肉输出的事情,团队负责这个功能的只有 3、4 个人,做一个省还好,要是放开到全国,想都不敢想。

Snail 只能打电话,把早晨刚通宵加班回家的同事又喊了回来,有的人甚至穿着拖鞋、套着薄外套就跑了回来,靠着同事支援的羽绒服,又一直加班到第二天。

(在行军床上睡觉的程序员,戴久了口罩耳朵疼,自制了皮筋支架)

当然,就算是熬通宵,人还是不够。就在 Snail 急得搓手的时候,何波直接找过来说,“我把肿瘤助手和健康卡的人全部调过来,你看着用。”

Snail 很难描述当时的感觉:“说不出来,就感觉鼻子有点酸,险些要掉眼泪下来。”

再后来,腾讯公司内发起了志愿者招募,不少本来已经在家休假的同事也主动加入,既有个人报名,也有团队“组团”加入的。

通过陆陆续续来到的援军,Snail 最后拉了一个群,群里最多的时候有 30 个人。

在这之后,产品团队又联合天衍实验室和地图的同事,用上了各种技术手段,一起来清洗数据。

这个过程中也有一些零零碎碎的问题,比如医院对了位置不对,或者位置对了医院不在了。所以,产品团队还要跟腾讯地图的同事合作,把 POI(Point of Information,信息点)的信息补充上去。

一天夜里的凌晨四点,Snail 发语音让大家休息一下,但是大家好像都没有睡意。一位负责运营的同事说,“没关系,我再盯一盯,争取上午的时候可以出来。”

1 月 26 日,国家卫健委宣传司联合腾讯, 正式上线“新型冠状病毒感染的肺炎医疗救治定点医院和发热门诊地图”。

半个月内,这份发热门诊地图累计被过亿人次访问,调用次数超过 10 亿次。

最高纪录:一天 7 个版本
1 月 15 日,公共卫生出身的部门老大吴文达提前给团队买了两大箱口罩,医疗健康事业部研发中心总监 Foowang 并没有想到,不久之后,“口罩”会成为国人手上的硬通货。

1 月 19 日,Foowang 陆续听到大家说,深圳腾大楼下两家药店的口罩卖断货了。晚上回去,一些同学说小区的口罩也没了。大家这才意识到,问题并不简单。

20 号那天开完会之后,Foowang 考虑了一个问题:怎么样基于现有的系统架构,以最快的速度把疫情专区做出来。

当务之急,就是迅速组建一支“精锐部队”,“我们要保证抽调最精干的力量,其次,要保证在现场响应速度最快。”

临近假期,一些研发人员已经回家。但是一些人听到消息之后,直接回来了,数据组的 Like 就是其中一位。

Like 原本是准备大年三十去女朋友家定亲。听到公司的电话之后,他就把定亲的事儿推到了国庆。Foowang 感到有些过意不去,“我们都说定亲重要,他说没有关系,放到国庆去也挺好的。我就觉得到时候国庆定亲的时候,我们是不是应该表示一下。”

让 Foowang 高兴的是,还有譬如杰西、飞哥等几位“老战友”。有一些已经转岗一年多的同事,也私底下问 Foowang:“哥,要干活了?带上我吧,不怂的!”

1 月 21 日晚 8 点半,产品的设计图出炉。

Foowang 说,“第一版本的很多细节逻辑、交付仍有缺陷。但是,时间不等人。在产品同事不断填充逻辑的时候,研发团队同步在写代码。要按照正常流程做完整测试肯定是不行了,大的 feature(功能)测试人员会过一遍,很多小的 feature(功能)就是开发人员自测。”

Foowang 说这句话是有底气的,因为从 2019 年 6 月份到 12 月份的半年时间里,腾讯健康的小程序完成了 60 多次版本迭代,“就跟高考一样,模拟题做多了,自己也就不怕了。”

1 月 21 那个通宵的夜里,所有人都没有睡,连腾讯健康小程序的负责人 Kyler 也是如此。通过腾讯的内网链接,Kyler 盯着研发的进度,边看边改。

1 月 22 日早上 6 点,研发团队的第一个 H5 版本开发完成;早上 8 点,H5 版本正式上线。

发版本只是刚起了一个头,更繁重的事情在后面。据 Snail 所说,团队负责的小程序每天迭代速度最高达到了 3 版。但这在 Foowang 看来是常态:“每天修 Bug、发功能,包括 H5 的版本,研发团队的最高记录一天发过七次版本。”

当然,如果要发版本,就得有人审版本,这件事落在了微信团队的头上。

因为临近春节,广州的微信团队暂停小程序审批,要发新版本也只能到节后。但是考虑到疫情,微信对所有的疫情审核都是最高优先级,微信也为这款小程序提供了专人配合支持,一旦做好马上审、马上发。

1 月 26 号微信对小程序正式放量之后,数据监测成了一个重要任务。为了快速迭代,每隔半个小时,负责数据监测的 Anny 和她的同事们就要更新一次数据看板,每晚还要连夜输出数据日报及对第二天的数据预测。

有一天,HRBP Maggie 联系 Anny 需要一个数据,Anny 说自己在医院。当时,Foowang 以为她是发烧了,心情很紧张。问过之后,Foowang 才知道她因为用眼过度,导致泪腺破裂。

Maggie 听到之后,直接拉上了 Foowang 和部门领导说:“不行,你们必须让她休息。”Foowang 一脸茫然地回答:“我们都不知道,她也不吭声呀。”

后来,Foowang 让 Anny 回家休息,休息了一天之后她又回了公司。不能打字,也不能看屏幕,她就在旁边闭着眼睛听同事反馈数据变化,然后给出自己的意见。靠着这样的方式,Anny 跟完了产品迭代的全部过程。

有一天,Foowang 去洗手间,听到 Anny 在楼道里跟家人打电话。这才知道,原来她的小孩也发烧了。(后来得知,Anny 的小孩子发烧症状缓解,排除新冠肺炎)

Foowang 觉得有些愧疚———“她提都没跟我们提过,觉得挺过意不去的,又不知道说什么好,只能把这件事做好。不然就对不起大家这么玩命的干。至于说其他人能不能看得见我不管。事情做好了,总能看得见的。”

除了身体上的劳累,真正让 Foowang 觉得委屈的是,产品的真实性遭到外界质疑。

和卫健委合作拿肺炎统计数据时,因为卫健委的数据准、但是更新频次固定。在这个短暂的“空窗期”中,各种小道消息趁机出来博眼球,也有人会趁机拿统计数字质疑、攻击腾讯的数字。

有人说,能击垮人的从来不是别人的非议,而是对自己的怀疑。

因为要处理的数据太庞大,看到那些负面消息的同事难免会怀疑自己是不是真的出了错,“他们会觉得自己‘有苦说不出,没法儿跟那些人辩解。’”

后来,Foowang 安慰大家说,“当你在做一件正确的事情,你需要面对的不是鲜花和掌声,而是很多质疑和挑战,而恰恰经受住了质疑和挑战的东西才弥足宝贵。”

巡检的后勤部队
相比于 Foowang,研发的老范和光哥更加默默无闻,他们的工作是和服务器打交道,也就是后勤部队的后勤。如果说其他同事的工作是“起高楼”,那他们的工作就是“打地基”。

QuestMobile 移动报告显示,从 1 月 24 号以来,腾讯健康微信小程序的流量 10 天上涨 70 倍。2 月 4 日,腾讯健康小程序日活突破 3000 万,成为最大的在线医疗服务小程序。

面对急速的流量增长,如何确保系统不崩?老范和光哥功不可没。

大年初一(24 日)早上十点,Foowang 向老范和光哥提了两个问题:随着版本的迭代和疫情的走势,服务器的流量模型会是什么走向?基于用户访问的核心路径,如何保障系统稳定性?

流量的不停上涨,让 Foowang 对原先预估的模型也没了底。事后证明,他们估的流量模型确实不太对,因为流量远远超过他们的预期。

Foowang 印象很深的一次是,有一天流量突然涨了 30%,第三天继续涨了 50%。但是第五天流量又暴增了 100%,接下来的几天都是如此,有一天甚至上涨了 200%。

这种情况下,固定的模型就不存在,一次性的扩容也不能一劳永逸。老范和光哥定了巡检的方法和制度:上午十点巡检一次,晚上九点巡检一次,每天下午还会有一次小的巡检。

巡检的核心,不光是看系统在过去流量冲击中有没有失败和过载,更要看系统还有多少计算余量,能不能扛得住第二天的用户需求。

最重要的是晚上的巡检。

Foowang 作过统计,每天的流量从早上六点半开始攀升,早上九点半达到高峰。因此,提前一晚的巡检既要看计算资源的余量有多少,又要对第二天的流量进行预估。所以,虽然晚上的巡检是十点钟开始,但是老范和光哥经常干到一、两点钟,甚至要通宵。

 

(从左往右依次是 Foowang、老范、光哥和其他质量保障团队成员)

每到了这个“让程序员睡不着觉”的时候,Foowang 总能想起 Kyler 曾经说过一句话———“你的 feature 少做一个可能就是被老板或者用户骂,但是系统扛不住,那是被全部人骂。再说了,(系统扛不住)你良心不会痛吗?”

对于腾讯的研发团队来说,判断“扛不扛得住”这件事情的标准,不是出现失败或者超时的概率,而是耗时的上升。例如,一个用户平时操作的响应时间是 100 毫秒,如果涨到 150 毫秒,即使还没出现失败,团队就要开始干预,把耗时降下来。

为此,老范和光哥带领质量保障团队几乎每天都在扩容,先后重构了几十个服务,为的就是将用户的响应时间控制在毫秒级。

 

(光哥深夜做系统巡检)

“重构的服务都是关键路径,这个压力非常大。所以研发团队的神经一直拉得非常紧。” 但是,在整个项目期间,无论是功能还是稳定性,Foowang 和团队在技术上没有出过任何纰漏。

在他看来,这项工作是整个过程当中极其重要的一环。

今年这个春节,就连一向挑剔的腾讯总办“产品经理”们,都没有一句挑剔系统性能的话 。这被 Foowang 视为最大的肯定———“大家想不起来我们,才是我们最大的成就。”

连接器和工具箱
帮产品设计逻辑、给 Snail 借兵的何波是一个在健康行业呆了将近 20 年的老兵,她以卫生系统记者身份,全程记录了 03 年非典的历程。所以在这次疫情中,何波帮助产品团队做了很多“顶层设计”的事情。

对比 SARS 与新冠肺炎两场时隔 17 年的疫情,除去非典遗留下的应对经验、防护机制以及医疗科研与诊疗能力的进步,何波认为,这次的“抗疫”战争中最重要的一股力量就是“互联网”。

她说,如果没有互联网,所有的信息都是靠媒体发布,必然是碎片和断层。而腾讯的互联网特性,就决定了腾讯健康的重心就是整合式信息发布,将单纯罗列的静态信息,变成一个可交互、可查询、可订阅的状态,并且将疫情、科普等信息服务延伸转化成 AI 辅助的发热自查、在线义诊等互联网交互式工具。

我们要承认的一件事是,发热门诊地图、线上问诊工具,这些对用户来说非常有用。但是,整个疫情防控过程中,地方卫健委和地方的医疗系统发挥了重要的作用,如果只有微信这一个入口显然太少。

所以 2019 年 1 月的时候,国家卫生健康委统计信息中心与腾讯就达成电子健康卡创新应用战略合作,以微信平台作为电子健康卡发放与应用的渠道,在全国范围内推进电子健康卡普及应用。

当然,因为推行时间不长,腾讯的电子健康卡目前只覆盖了全国 20 个省、直辖市和地区。

现在,腾讯已经着手与各地卫健委合作实现电子健康卡升级,推出三色健康码。通过电子健康卡二维码“红”“黄”“绿”三色显示,进行风险信息提示,协助管理部门实现分区施策,分人群管理的目标。这样既延续电子健康卡作为医疗机构就医凭证的功能,又成为疫情期间的通行健康凭证。

电子健康卡产品负责人一凡表示,健康卡团队本身的定位就是 to G、to B 再 to C,帮助政府和医院将医疗服务延伸到健康服务,让用户通过这张卡管理自己的健康。

2 月 6 日,腾讯发布了“新冠肺炎疫情服务平台”,面向全国各省市卫健委、区县卫健局和疾控中心、医疗机构等提供疫情服务聚合工具,实现微信公众号、小程序、app 的快速接入。目前,新冠肺炎的疫情服务平台已经扩展到 22 个省份、60 个市级的卫健委。

服务平台有两个特征,一个是标准化,是集成腾讯能力的工具箱,政府和卫生部门可以从中选择标准化的工具;另一个是本地化,是为本地提供更符合当地疫情的定制服务。

所以,健康卡团队的工作相对较重:跟各个地方的卫健委和医院合作,考虑怎么跟医院系统打通、怎么获得各个地方卫健委政策的支持,了解他们的需求后,再需求反馈给 C 端团队。

例如,疫情地图。有些地方希望扩大地图的颗粒度,扩展到区级、县级甚至是街道,那腾讯就帮他们去做,从及时性或者颗粒度来讲,这又比标配版的产品更加完善。

再比如在线问诊。通过电子健康卡,把当地具备互联网医院资质的医院连接到服务平台上来,让患者通过发热自查的小工具发现问题后,能够通过在线问诊找到合适的医院、医生,进一步答疑解惑,隔离病毒不隔离医疗服务。

对于没有互联网医院能力的医院,腾讯健康提供 SaaS 服务,联合服务商给他们提供在线问诊的云平台,这也是一种本地化服务。

值得注意的是,疫情服务平台这样的事情并不是腾讯一家在做,比如阿里的钉钉也在浙江等省份有接入。

那么,留给卫生部门的一个问题是,疫情数据如何追踪?比如说,用户在一个平台上填报了个人疫情信息。那么,他就很少会在另一个平台上填报。

一凡说,数据的归拢、真实性问题确实存在,但是国家推行电子健康卡的优势就在于实名制及跨域唯一主索引。健康卡跟医院的就诊信息是打通的,从发热登记到医院就诊与否是可追踪的。

一个比较好的标杆是,湖北省宜昌市与腾讯的合作。

现在,宜昌健康卡合作接入医院 12 家,宜健通小程序累计访问人次达到了 4000 万。疫情模块(健康自主申报、疫情动态查询、疫情科普等功能)累计使用人次 600 万,其中健康自主申报,累计使用人次 530 万。

很早之前,腾讯就和湖北省宜昌市在做电子健康卡工作。目前,宜昌市民在做体温自主上报工作,所有用户一天不漏、一个不漏。怎么判断这个人到底有没有上报?就在于用户拥有的那张电子健康卡。

这张卡上,一方面记录了他的电子健康档案,第二方面是他的就医记录,第三方面是每天的健康自查和体温上报,这样市民的数据能串联起来,帮助防疫指挥。

当然,现在很多地方不具备这种全市级别的数据管理方式,在一些信息化能力薄弱的地区,重复、错误上报的问题确实难免。

不过,可以预见的一点是,在这次疫情过后,基于城市级的医疗信息平台的建设工作,将会成为各地政府和卫生部门的当务之急。

“没想到会是今天”
作为腾讯健康小程序的总指挥官,kyler 没有想到腾讯医疗健康会以今天这个姿态出现在人们面前。至少,不是现在。

“本来去年攒了一年的劲儿,今年是准备起跑,没想到疫情之下,起跑直接变成了冲刺。”

2019 年 4 月,就有媒体曝出,“微信支付”页面将增加“医疗健康”入口,隶属于腾讯服务版块。当时,腾讯方面也给出回应:3 月 18 日起,部分深圳微信用户可以看到该入口,未来将逐步向其他城市微信用户开放。

但是,说完之后,腾讯的态度仍然很“克制”———从去年的 7 月到 10 月,腾讯医疗健康的小程序仍处于灰度测试状态,只是在深圳、武汉等部分城市开放了服务。

在这次的采访中,Kyler 说,腾讯医疗健康并不是还没有准备好,只是自己心中一直有一个小程序放量的原则:线下的服务有多少能够和线上进行连接。

1 月 20 日那次 6 个小时会议的前几天,Kyler 刚做好 2020 年规划,制定了全国各省循序渐进上线的发展。但疫情的突然加速,让大家意识到,刚做好的计划要打破了。

Kyler 也承认,“当时没有想到肺炎会蔓延地这么快。”

就像开头提到的,与腾讯总办的微信群讨论一样,抛出的第一个问题是“疫情发生了,腾讯该做些什么?”。大家下意识的跳过了“要不要做”的讨论,直接进入了执行阶段。

Kyler 被告知:“只要是对用户有价值的事情,只管去做。”

 “产品、研发、商务、测试、项目管理、设计,这是医疗健康的资源。此外,还有医典团队的全部资源。整个医疗线该打出来的牌全都打出来了。”

这就意味着,还有很多事情或许没有准备好。

比如,技术的风险,春节是微信的洪峰流量时刻,在这样一个时候面向全国上线,腾讯健康小程序必然会面临巨大的压力。

又比如,如何保证疫情产品的准确率和权威性。

所以,从这两个角度考虑,从 1 月 20 日之后,所有以往跨部门的困扰全部消失:腾讯健康、腾讯医典、腾讯新闻、腾讯地图、微信城市服务等腾讯团队进行合作;而假期招募内部志愿者的公告一发布,报名的人数是需要人数的几倍。

 “在这一刻,对我们来说,只有一个目标。我们内部有很多群,有一个工作组来确保这个信息是 7×24 的响应,有任何问题大家一起扑上去。”

在一个小时的采访中,Kyler 提到最多的就是价值。“只要这件事情值得做,所有风险我们都愿意来承受,还是要看这件事情的价值。”

“价值”,似乎也呼应了马化腾去年提出的“科技向善”新使命———在商业上实现自己的价值,并不是唯一的目标。

我们尝试着让 Kyler 为这一次腾讯医疗健康团队做的事情提炼一个核心,他思考了一会说,用了“公益”这个词。“所有的一切都是以公益为核心驱动,任何和商业关联的计划在这个时候,都显得无关紧要。”

一封来自马化腾的邮件
抱着梦想而活着的人是幸福的,怀抱梦想而死去的人是不朽的。

2018 年 9 月 9 日上午,9 点 19 分,一封署名“Pony、Martin 及总办”的邮件发到了每个腾讯员工的邮箱。

邮件中写了这么一句话:我们更希望从现在起,将 99 公益日交予社会,并让 99 公益日进化成更常态化、持久化的“久久公益日”———让付出者体会公益的快乐,让行动者收获信任的价值,让参与者创造多样的生态。

马化腾补充说,“公益理应是一个开放与包容的场域,它不仅是少数人的权利,更应是多数人的福祉。贡献资金之外,让更多人卷入和参与,是一件特别了不起的事情。”

英国有一位和莎士比亚同时代的诗人约翰·多恩。他在自己的《沉思录》第十七章中说过这样一段很有名的话:

“谁都不是一座孤岛自成一体,而是广袤大陆本身;海浪每冲刷掉一寸土,它就少了一块……任何人的死亡都使我受到损失,因为我包孕在人类之中。”

推荐器件

更多器件
器件型号 数量 器件厂商 器件描述 数据手册 ECAD模型 风险等级 参考价格 更多信息
SN74LVCH32373ANMJR 1 Texas Instruments 32-bit transparent D-type latch with 3-state outputs 96-NFBGA -40 to 85

ECAD模型

下载ECAD模型
$52.41 查看
AD9517-4ABCPZ-RL7 1 Analog Devices Inc 12-Output Clock Generator with Integrated 1.6 GHz VCO

ECAD模型

下载ECAD模型
暂无数据 查看
SN74CB3T3245DGVR 1 Texas Instruments 3.3-V, 1:1 (SPST), 8-channel FET bus switch with level shifter 20-TVSOP -40 to 85

ECAD模型

下载ECAD模型
$2.91 查看

相关推荐

电子产业图谱