厉害

这是惊恐发作，属于焦虑症。

我自己差不多用了一年的时间才完全康复，过程也很曲折。

主要是因为作息时间不好、压力大、咖啡刺激。交感神经和非交感神经相当于一个油门一个刹车。因为外界和自身的刺激，半夜非交感神经开始踩刹车的时候，自己强行踩油门让自己清醒之类的。时间久了，这两个配合出现问题。半夜可能交感神经突然介入，其实心跳也就七八十，但是感觉 100+。就好比你马上要当着几百人上台演讲、或者遇到了危险，心脏立马怦怦跳，这是正常的交感神经介入。只不过交感神经在不正常的生活环境、心理压力和外界刺激下，或者在你失眠的时候突然介入了。

推荐你看一本书《焦虑症的自救》 https://book.douban.com/subject/35266331/

做个全面体检，证明没有任何器质性问题，是纯粹心理问题。

然后适当降低咖啡因、少熬夜。在生活和工作上找找压力的来源，调整一下。

@ryan4yin 感谢反馈！

请问你是说像 SEARCH(), SUM()之类的函数吗还是 Metrics Insights 类 SQL 的查询语句很难写？

如果能给几个查询例子就更好了！

我可以牵头看看如何改善这一块的用户体验。

*EC2 Detailed Monitoring

@ryan4yin

如果是 CloudWatch 监控指标相关功能不好用，可以举几个例子吗？

AWS 资源产生的基础设施监控指标一般都是免费的，除非开通 1 分钟精度的 EC Detailed Monitoring 单独收费。

@hlayk 可以是可以，但是大家在这里建议的是业界比较认可的做法。

如果返回 200，前端根据 code 字段做相关处理，那后端做可用性相关的监控就比较让人头疼。
不知道你们有没有对后端的 canary test，中文好像叫拨测？将来持续测试后端 api 的话，正常来说判断 api 是否成功就是使用这些 http respond code 。如果后端都是返回 200，那相关的测试也无法从 http respond code 获知是否成功，需要解析里面的自定义 code 才知道。

后端参数校验错误应返回 400 HTTP respond code 。
message 应返回有帮助性的错误信息，比如请求参数里的 XXX 字段长度不能超过 YYY 等等。
code 字段可以是自定义错误码，一个自定义错误码对应一个异常。

Retrofit 抛异常是对的，前端应该 catch 这个异常并做相应处理。
比如 catch 异常并分析 respond 是 400，打印日志，看是否需要提示前端用户参数错误或加强表单验证。
如果 catch 异常并分析 respond 是 500，打印日志，上报监控指标，配置 client 进行请求重试。

14 年来爱尔兰，确实发现信息不太畅通的问题。
这么多年也有 0086，新岛，华人志。

感觉有这样几个问题：
1. 爱尔兰华人还是少，市场小
2. 2+2/3+1 项目多，留下来的学生少。做的好也很难靠用户推荐给用户。
3. 老华人 /留学生都是上 6park，现在的学生在电脑刷论坛的少了

我的理解是这一套搭在不同地域或者同一区域的不同可用区然后前面加负载均衡。

可以自己先做一下测试，比如在一个可用区启动 2 个 2C4G 和一个 8C16G，给前面两个 50%的负载，后面一个 50%的负载。不断增加请求，看看 CPU，内存，硬盘吞吐等等指标的情况，找一下性能瓶颈再决定单机还是多机。

前两个月也可以先用 on demand 看看，太着急包年买可能会造成浪费。

爱尔兰 MongoDB 欧洲总部也是个选择。

也要看工作态度。

没进展是他很努力只是不善于提问，喜欢自己研究还是工作态度一般？

努力但是没产出可以慢慢引导。
态度不行的话就不是一时半会能转变的了。



我之前带的实习生，每次我挤出时间来手把手的教，5 分钟就不耐烦了要去洗手间....
工作不了俩小时就去打乒乓球....一天好几次 : )

1. 我觉得应该按 SLA 索赔阿
2. 2 楼说的可能性挺大，单个异常用户是有可能影响整个服务的，所以断掉了你的链接。可以让客服核实一下，如果确实有这个需要的话，应该让他们扩容。

AWS Beanstalk 东京结点 不香吗？

工作半年以后吧。

比如如何组织有效的会议，可能 10 分钟以后大家发言就跑题了，组织者可以及时把话题拉回来。

比如及时 escalation，定期给 manager 汇报进展和能否按时完成和风险。而不是扛到最后几天才说可能完不成。

比如需要整个组意见达成一致的会议，其实应该提前跟组里每个人私下沟通了解每个人大概的意见。而不是在会议上撕一个小时没任何结果。

还有如何管理你的经理等等...

推荐《软技能，代码之外的生存指南》

我的建议是开几台机器，把你的服务部署上去，然后做 load testing。
看看你单机和集群能处理多少请求，然后如何提高。
在这个提高请求处理能力的过程中，你就会慢慢学到。

言论仅代表我个人：

我们有官方文档指导你在 AWS 上面部署 MongoDB 服务： https://s3.amazonaws.com/quickstart-reference/mongodb/latest/doc/MongoDB_on_the_AWS_Cloud.pdf

另外官方 Atlas 也是可以选择 AWS 的。