NAIE硬盘故障预测服务体验及评测如下，整体体验比较顺畅。体验报告如下方附件。若其中有原则性问题，请指正。华为云帐号： suse-dev

华为云账号：z-LoyalGhost（LoyalGhost）群内微信号昵称：灰尘（Dirt） WANSBhhc

微信昵称：胡余雷leo体验及评测内容请见附件，还请各位大大指正

第23期华为体验官-NAIE硬盘故障预测服务体验及评测-fjqsun账号信息：fjqsun群内称呼：@~@详情见附件 

详情请见附件，欢迎各位大佬指正。

微信昵称：风吹草动试用体验了NAIE硬盘故障预测服务的一点体验

详情请见附件，欢迎各位大佬指正。

本期体验产品：NAIE硬盘故障预测服务体验形式：      本次体验采用有奖征集体验评测报告+群内交流反馈的形式。筛选30位体验官，按照硬盘异常检测模型服务操作指导书（详见附件）体验产品并按照测评维度输出产品体验评测报告。我们会按照评测体验维度、深度、意见建议等方面，从中筛选出20份高质量体验报告，给予礼品奖励。中奖率超高哟~~☆奖品设置如下☆ 金牌测评体验报告奖：3名奖品：荣耀体脂秤1个                            银牌测评体验报告奖：7名奖品：华为云定制双肩包1个  体验评测报告优秀参与奖：10名奖品：精美鼠标垫1个☆产品体验评测报告内容要求☆产品体验地址（本次体验免费，详见附件免费试用步骤）：https://telcloud.huawei.com/domainconsole/?region=cn-north-1_softcomai.competition.201&locale=zh-cn#/disk/disk-detection产品介绍：       基于业界标准的硬盘S.M.A.R.T指标集，提取30+关键特征构建AI模型，输出硬盘的健康状态检测结果，并预测硬盘故障，帮助客户构建硬盘的主动式故障处理机制，保证系统和业务的可靠运行。产品使用说明：请点击链接查看https://support.huawei.com/carrierics/Model%20Training%20%26%20Domain%20Model/Latest%20Version/topic/view.do?portalid=1568165341672&hdxfileid=DOC29540&pidid=pid_bookmap_0152280381&topicid=TOPIC_0152280382&relationid=default&path=DOCNAVIEB75603CC6A148C49D9A2952D28645D2用户报告体验维度：（1） 使用体验:从最开始接触使用NAIE硬盘故障预测服务到最后操作完毕，请简短概括下您的使用体验（2） 需求建议：  A.    是否容易上手，硬盘故障预测服务内使用帮助是否能解决遇到的问题？需要增加哪一类的预测特性；  B.    对于产品性能，操作便捷性，可视化界面等有什么建议；  C.    你觉得哪一模块可以使用其他更优的方案替代；  D.    使用过程中有哪些不好的体验，是否出现异常，无反应无提示的状态；（3） 满意度及推荐度：当有存储或服务器设备的硬盘故障预测需求时，您是否愿意推荐NAIE硬盘故障预测服务？理由是？体验评测报告交稿时间：2020年3月24日 16:00前，请报名评测的体验官将评体验测报告发帖上传到华为云社区开发者交流论坛中，分类选择（体验官）。并同步微信告知小助手（微信：hwykfz1）微信号。2020年3月31日 16:00前，将获奖信息告知体验官。 体验报告发帖地址：https://bbs.huaweicloud.com/forum/forum-557-639-1.html发帖时，请上传已填些完毕的任务卡（word），并在帖子内标注微信群昵称，以便评奖时使用 。

详细见附件

欢迎各位大佬批评指正

总体评价： 1.因为不熟悉运维，如果光从数据挖掘的项目来看是没有看出什么问题。但如果真正部署到生产环境中，却需要与syslog、SNMP等进行联动，然而在本次的NAIE体验中没有看出这些相关的操作，感觉NAIE像是之前MLS的改良版。 2.包依赖问题，能否只下载一次呢？用sklearn如果在本地，就算是几万行数据+sklearn也是秒算，而NAIE每次都花1分钟来下载，会让一部分人着急 3.自带Demo全流程，这点好评 4.明明是用sklearn，却要选TF，这点比较奇怪 下面是标准问题： A.是否容易上手，模型训练服务内使用帮助是否能解决遇到的问题，需要增加哪一类的使用帮助； 答：容易上手，但指导书最好不仅仅是只有图标，并且有全屏截图标明位置 B.对于产品性能，操作便捷性，可视化界面等有什么建议； 答：见上面的总体评价 C. 你觉得哪一模块可以使用其他更优的方案替代； 答：数据预处理上，最好有相关的指导说明。 D. 使用过程中有哪些不好的体验，是否出现异常，无反应无提示的状态； 答：主要是从秒算，变成花2分钟，不习惯 满意度及推荐度：当有AI平台需求时，您是否愿意推荐NAIE模型训练服务？理由是？ 答：满意度(6分，10分满分来计)，推荐度(1分，10分满分来计) 不愿意推荐NAIE，因为用sklearn在本地是秒算，也没有像ModelArts那样需要云端大算力的需求，并且没有提供从SNMP、syslog一直到推理运维AI流程。

Dear小助手：    以下是我的体验官有奖体验第19期 | 华为云NAIE模型训练服务体验及评测的评测报告，请查收！    报告以附件形式呈现，依然发布两个版本（word、pdf）便于查收，谢谢！

作者：黄隽（Charlie）背景敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下：问题一：团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？问题二：团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。问题分析以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下：问题一：团队只关心数字。团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算，而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间，即数字。也就是说，团队过于追求数字的准确性，忽略了估算的真正核心价值。问题二：团队过度承诺。团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫，领导施压（与资金和绩效挂钩）。比如，领导经常说：“大家加把劲儿，我相信大家的能力，努力一下，这些需求你们是可以做完的，大家的表现会影响绩效评估，年底咱们多发点资金。”所以团队常常了了估算、一言堂（架构师说的算）、猜测工作量，最后造成过度估算，经常完成不了迭代目标。小结“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知，团队成员并没有了解估算的真正核心意义，导致团队狭隘地理解成估算就是要最后的数字，而且在有外部压力的情况下团队也顾不上认真估算，盲目地过度承诺工作内容。其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容，这样可以更好地理解估算，然后再针对以上2个问题进行解答。解决措施利用核心概念树立正确认识在这里，我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如，不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。通过上一篇《估算第一篇：利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友，建议可以花一点时间阅读上篇文章，也会有助于做好估算。现在我们一起了解一下估算的4个核心概念，以便理解估算，树立正确认识，然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示：问题估算核心概念问题一：团队只关心数字。利用“区分准确与精确”：估算应该准确，但不必过分精确。利用“估算相对大小”：人们更擅长对大小进行估算，而不是绝对大小。问题二：团队过度承诺。利用“团队一起估算”：在估算活动中，团队成员一起估算，结果更合理。利用“估算不是盲目承诺”：估算不是承诺，重要的是我们不能这样认为。区分准确与精确估算应该准确，但不必过分精确。比如，我们估算某产品是10888人时（是怎么做到这么精确的？）。其实这是很荒唐的，过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量，得到一个刚好的、大致正确的估值，如做估算时工作量和准确度的对比图所示：做估算时工作量和准确度的对比图在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。团队成员在做一项工作的同时，难免会遇到各种各样的问题，所以为了做到准确估算，在做估算时，任务的拆分一定要适当细，只有细化后，团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的，如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时，需要了解是不是遇到了什么困难，需不需要帮助解决。超过16小时的任务建议需要再细化。在做估算时，我们经常会填写预计工时和实际工时。预计工时是我们估算的结果，实际工时是对估算结果的检验。我们允许预计工时的不准确，但是一定要填写准确的实际工时，这样才有助于我们在估算不准的问题上有充分的证据做分析，然后改进，进行良性循环。随着团队成熟度的提高和对业务的越来越了解，估算准确度经过几个Sprint会有所提高。估算相对大小建议使用相对大小而不是绝对大小来估算PBI。比较所有条目，然后确定某个条目和其它条目的相对大小。如下图所示，讨论一个杯子相对于另一个有多大比较容易，但对于杯子中可以盛多少绝对数量的液体，我们可能没有概念。相对大小对比图人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。当然，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍，可以阅读下一篇《如何估算第三篇：估算故事点》，其中会介绍一个具体实践，即故事点估算。团队一起估算而不是个别人估算在估算活动中，团队成员一起估算，而不是仅仅由项目经理、架构师、主要程序员估算。简单说，是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场，但并不实际参与估算。产品负责人负责阐述PBI，并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小，当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏，不管怎么拆分任务，甚至是不拆分任务以story为最小颗粒度，那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task，比如测试和开发人员手头上的task，那就没有统一标准，根据具体task内容估算。 记录工作项工时，可以参考华为云DevCloud，工作项工时显示如下图所示。需要客观估算而不是盲目承诺估算不是承诺，重要的是我们不能这样认为。举一个例子，如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效，那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。所以，团队成员在没有外因干扰情况下，大胆、放心的估算工作量，也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成，在Sprint进行中，会让团队成员根据实际情况去更新实际工时。例如，昨天更新4小时，今天又更新4小时，那就把实际工时更新为8小时。当Sprint结束后复盘时，我们会整体看这些预计工时和实际工时的数据，主要是为了提升团队/个人估算水平。如果估算和实际有明显差距，是需要深入分析的。本身也是期望通过估算促进做简单设计。应用正确认知处理问题，做好估算以上是估算的核心内容。现在我们回头看看之前的两个问题。问题一：团队只关心数字。面对这个问题，作者主张团队成员不要只是关心数字，还要关心投入产出比（ROI），避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。从估算的核心概念“准确与精确”中了解到，在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到，人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。因此，我们在做估算时：首先，要把握一个估算的适度准确原则，不要过度浪费。其次，为了降低难度，团队更好的达成一致意见，可以采用相对大小方式进行估算。问题二：团队过度承诺。面对这个问题，作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算，避免过度承诺。从估算的核心概念“团队估算”中了解到，估算活动是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说，真正完成工作的人才会对工作需求内容更用心，也更了解团队的速率，他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到，估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下（不建议奖金、绩效明显挂钩），大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。有些朋友可能会问，如果得到的估算结果是靠谱的，完成需求就是那么多工作量，产品上市日期也已经确认，那么怎么办？如果真的是因为产品上市日期已定，有上线压力，团队一定要承诺过多的工作内容，那么就确保团队把故事拆分得更细，即使他们交付不出设想中的高档理想的全功能版，至少也能每个典型的功能领域多少交付一些内容。说到这里，还是不建议这样做，尽量采用高价值的事情优先做原则，与客户协商，产品经理对需求排好优先级，优先实现高优先级的PBI。了解更多以上是针对不了解估算核心概念而导致估算活动不理想的解决措施。朋友们看到这里，相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣，欢迎阅读接下来的关于估算的另外两篇文章，即《如何估算第三篇：利用故事点做估算》和《如何估算第四篇：利用2种常见方法做估算》。参考附录Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。Rachel Davies. Liz Sedley.敏捷教练[M].北京：清华大学出版社。附件：如何估算第二篇：利用核心概念解决估算常见问题V1.2.pdf[hide]链接: https://pan.baidu.com/s/1qQHK_WxG_9YQOKIm8MO8aQ提取码: g6vn[/hide]

测评详情请见附件，各位大佬可以提出不同意见！

华为云NAIE服务体验报告Motozilog智能化运维取代传统的人工运维是近年的一个趋势，特别是互联网场景下动态横向扩容、微服务、CDN、NoSQL等应用越来越多。但是从事一线运维人员通常是刚毕业的学生、编程基础较为薄弱、学历也不需要本科（毕竟公司是需要节省成本）。是否有一种服务能像ModelArts那样能使不用懂AI原理的人也能“傻瓜式”进行AI应用运维场景呢？带着这个问题，参与了华为云NAIE服务的体验。按照体验指导，创建硬盘检测。本来以为NAIE是为运维来做，想不到是为ISP的运维来做。 模板自带演示数据集，这点好评并且还能在线预览数据 接下来是特征工程，下载示例的python文件瞬间感觉“隔行如隔山”，感觉与平时用的numpy、sklearn不同啊！瞬间蒙掉……如果是传统的数据挖掘项目，一般是数据清洗→数据转换→特征工程→训练→推理。但NAIE这个项目就看得有点蒙了。 模型训练总算见到熟悉的sklearn了。 然而按照指导书上却是选Tensorflow，这就有点奇怪了。  训练运行时，更晕了！跑Demo居然还要一堆包依赖….... Demo看来应该要与时俱进啊来到这里我就奇怪了，max_features怎么与平时的随机森林不同，随机森林的features是选多少个features作为一棵树啊。看源代码才知是这样。按照指导，设置最优超参数再训练，依然是要解决包依赖问题推理同样还是包依赖问题跑完 总体评价：1.因为不熟悉运维，如果光从数据挖掘的项目来看是没有看出什么问题。但如果真正部署到生产环境中，却需要与syslog、SNMP等进行联动，然而在本次的NAIE体验中没有看出这些相关的操作，感觉NAIE像是之前MLS的改良版。2.包依赖问题，能否只下载一次呢？用sklearn如果在本地，就算是几万行数据+sklearn也是秒算，而NAIE每次都花1分钟来下载，会让一部分人着急3.自带Demo全流程，这点好评4.明明是用sklearn，却要选TF，这点比较奇怪 下面是标准问题：A.是否容易上手，模型训练服务内使用帮助是否能解决遇到的问题，需要增加哪一类的使用帮助；答：容易上手，但指导书最好不仅仅是只有图标，并且有全屏截图标明位置B.对于产品性能，操作便捷性，可视化界面等有什么建议；答：见上面的总体评价C. 你觉得哪一模块可以使用其他更优的方案替代；答：数据预处理上，最好有相关的指导说明。D. 使用过程中有哪些不好的体验，是否出现异常，无反应无提示的状态；答：主要是从秒算，变成花2分钟，不习惯满意度及推荐度：当有AI平台需求时，您是否愿意推荐NAIE模型训练服务？理由是？答：满意度(6分，10分满分来计)，推荐度(1分，10分满分来计)不愿意推荐NAIE，因为用sklearn在本地是秒算，也没有像ModelArts那样需要云端大算力的需求，并且没有提供从SNMP、syslog一直到推理运维AI流程。