还是得看具体业务和目标用户。

国内社交、支付、应用市场入口都被 BAT 把持，二维码也基本是微信和支付宝的入口，即便不考虑浏览器的问题，如何让用户安装 PWA 应用都是需要调研的。

个人感觉目前局面，非 BAT 厂家对 PWA 都是支持的，至少目前来说是可以绕开 BAT 入口的好办法，更何况还有 Google 站台。而 AT 两家，明面上应该不会阻扰，但我真想不出有什么理由让它们积极支持推进。

除非能有什么重大事件能改变当前的局面——比如谷歌入华什么的，大概会一直这样吧。

JSON 类型也避免不了数据量过大的问题，反正查找算法还有数据结构就那些。可以预见的是热门标签的 doc_ids 增加是非常迅速的，大表还能分表解决，大字段该怎么解决？

通过文章来查标签好解决，但是标签反查文章，用关系数据库真不好解决。无论采取那种结构，查询速度明显会因为标签对应文章数据量增加而变慢。

感觉要么做成延迟生效，将查询结果缓存一段时间（不然被 cc 也够呛），追求实时的高一致性技术要求很高。

@SuperMild doc_ids 这个字段长度会非常大，而且文章修改标签时会相当蛋疼 。

dhcp 和 dns 有一些额外 option，可以实现服务发现，比如 http 代理服务或者 KMS 服务之类的。

https://it.cornell.edu/software-licensing/creating-dns-records-accessing-kms-server

https://technet.microsoft.com/en-us/library/cc940962(v=ws.10).aspx

另外有些网络架构下也会用三层交换机实现 HDCP，做 802.1X ，可能利用 Linux 也有类似的实现吧。

已经上线的项目，就算能解决初期造遗留的问题也需要很大的代价——技术债务越晚偿还代价越高，根本不是多个岗位能简单解决的事。

要是真有专业点的运维或者 DBA 也根本不会出现现在的问题。

说白了就是“短期高估”——期望一个运维 /DBA 能解决所有问题；“长期低估”——运维 /DBA 又没多少工作量，专门请一个太浪费，让开发顺便干了就行。

有万兆网络才能体验了，虽然价格还是贵，不过明年家用级万兆电口产品应该会开始铺了。

阵列不等于备份，对存储系统而言只要性能有需要，硬盘只是消耗品。

看看 daocloud 的免费版本能不能满足，不行的话只能由简单到复杂方案自己实践评估一下了。

新生事物在早期本身就是有很多问题的，Docker 确实解决不了所有问题，有自身的缺点，也会带来新的问题，不过搞软件工程应该知道的第一件事不就是“没有银弹”吗？

在技术未完全成熟时无脑拒绝和无脑跟风本质是一样的，提早作出判断收益才会更大，否则等着别人直接把你换掉 ¯\_(ツ)_/¯？

那些高大上的企业的容器实践分享可是实际存在的，自私的讲，出于丰富自身技术阅历考虑，也得尝试一下吧？

@gdtv 任何事情都是有代价的。

如果一个技术带来的收益，超过带来的缺点和问题的成本，那么就是可以考虑的。

每个项目、每个人所衡量的收益、成本不同，没必要拿来作为唯一准则。

小公司不都是开发“顺便”解决掉这个问题么？

之前待的公司后台要我把服务器换成 win7 试试你能信？

既然不是为了 GPIO 还是买 x86 平台比较好一些。

先退款呗，还能怎样。

考虑到屁股所处的位置，这样的言论是没有问题的。

选择自由的权利意味着也要承受自由权利的代价。

Alpine 有个蛋疼的地方，Android 编译用到的 aapt，老点版本是 32 位的，新版本是 64 位的，我没找到可以同时可运行的办法。

https://www.v2ex.com/t/323425

使用 DNS 认证方式即可

@x18960

不不，我不是大佬。

我只是认识到这个问题本质上是钱的问题，也是个人无法解决的问题之后放弃治疗了。

静态页还好，动态信息请求打死数据库什么的才叫绝望。

@x18960

DDoS 有了解，攻防技术相关的文章都看过很多，我（个人）得出的结论是：大多数文章所写的优化 TCP 参数、内核句柄等方法都是无效的。

反射式 DDoS 带来的瞬时攻击流量根本不是这种方法可以防御的，而这些“优化”带来的代价也决定了无法默认开启。

云平台免费的 DDoS 流量的提高了攻击者的门槛，而不是有效的解决攻击问题。

对于小公司大多数情况下云平台提供的免费 DDoS 流量足够防御，而超过这个限度的，只能看运维能掌握多少资源罢了。

说到底，防御 DDoS 完全就是烧钱，想通过自身力量低成本快速解决攻击带来的问题这种期望本身就是不靠谱的。

CC 方面主要还是清洗流量，如果预期目标是对正常业务不造成影响，我（个人）觉得这个级别的预期难度怕是要从架构上就要做准备才行（多级缓存、读写分离等等）。

应用层面的优化是要做的，否则投入的成本会很高。换个方向说，如果业务真的有这么重要，那么这些基本问题也通常会因为在 QA 流程中有性能评估而规避掉。

而对于应用层面有缺陷，也没有前期性能评估的项目，运维除了靠 WAF 之类的流量清洗产品挡一下、加几台服务器之外还能有别的更好的办法么？

PS：如果真的精于安全攻防的话我（个人）会选择去干灰产或者找家大公司洗白¯\_(ツ)_/¯。

@49degree

1. 监控方面确实需要补充。
2. 感觉配置 RAID，定期备份，硬件选型这些跟开发搭建开发环境一样是基本要求，所以根本没想着要写，看来得改下观念了。
3. jenkins 我是参考 https://www.cloudbees.com/sites/default/files/cje-study-guide-2017.pdf 的内容学习的，去掉了 base cloud 的部分。有完成过一个项目整体从开发到部署（ saltstack ）的流程，不过小公司没测试，只试验性的对接过 FitNesse 做 API 的回归测试（因为测试用例没有人更新，随着项目变化最终废弃）。

容器方面考虑到实际的集群经验无法获取，所以主要精力是放在 Docker Swarm/K8S 之前的部分。

我也很想知道如何做或者说如何表述才能有“足够深入”的感觉，还请赐教。

4. 安全方面，HTTP 协议的相关安全问题还是有了解的，常见的 HTTP 攻击，CC、回放、中间人这些也有做过一些方案（ APP 相关）。

但是感觉在这个问题方面，作为运维很无力。最小权限、补丁（平时也关注 CVE 漏洞库和一些国外相关资讯网站）这些都只是基本，但是很多安全问题都是应用层上的，运维没有高性价比的解决方法。

当然，这些结论仅仅是我根据自身知识而产生的，也许专业的安全人员有更正确的观点。

@hanxiaomeng

实际简历跟这里的内容还是有些差异的，工作年限已经按你的建议修改，3q。

现在的难点就是“如何获得足够大的生产规模的实践经验”，也明白以自身的境地需要一些“运气”，但这个就不是我能控制的了，只能尽量多尝试各种方法来提高概率。

个人预期的首选目标也确实跟你分析的一样是电商、游戏、IoT 行业，plan b 是业务合适的教育、医疗行业。

虽然目标明确是好事，不过这也提高了我就业的难度，现在这个时间点要找到一家规模合适又符合技术栈的公司愿意招我入职还是比较难的。

@402124773

我也不知道自己有哪里能算得上突出的，因为没横向比较的参考。

10 月份开始面试到现在，尝试不同的突出方向，比较成功的方向是 Jenkins 和 Docker 相关，也有一家对我个人兴趣方向（树莓派、智能家居）有兴趣。只有一家问过我 HTTP 协议相关的问题，不过面试官应该没我熟悉这块，问得很浅，一笔带过。

主要的问题还是在于数据库以及一定规模下 Linux 服务器生产实践经验这两个部分。

还有个比较随缘的是个人技术栈与公司技术栈契合度——有两家倒是满意 Jenkins 和 Docker，但我对 Java Web 这块完全不了解，直接 Over。

当前的策略是继续选择 CI/CD 和 Docker 方向，顺便为了 Plan B 继续撸 Python Web。

@greyterry

个人愚见：做得好，不如让人相信你做得好，这样才有机会证明自己能不能做好。直白的说我的博客、GitHub 还有这篇贴子，都是出于这个目的而准备的。

至于运维这个岗位嘛，明明是个深度和广度都需要积累的职位，但偏偏大多数适合初级运维的地方根本不需要初级运维。

讲实话，个人觉得中级以上有开发能力的大多数应该会选择转成开发——毕竟可以少操心很多事，而且薪水也更高。