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 还有这篇贴子，都是出于这个目的而准备的。

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

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

@privil

监控的目的是要对整体应用服务有足够的掌握度，根据掌握度的需求级别需要做的事情差异还是很大的。各个维度的监控数据必须横向分析才能完全掌控应用层面各种问题原因，这种事情想做到还得加上日志收集才能达成。

小规模服务的把握度和需求都比较低，云平台的监控是足够的，可信度这个问题在选择云平台时就已经有答案了，再来纠结也毫无意义——毕竟用户也没有任何方法能监控到物理机器。

而规模到一定程度时，需要完成的工作也并非是单个人的力量可以完成的，以目前主流的各种开源技术解决方案、架构来看，这个工作必须是有团队才能支撑的。

我的目标并非是成为 DBA，在只需要满足运维岗位对数据库的掌握程度这个提前下，对手搞多少年 MySQL 影响不大。

反过来讲，如果一个公司岗位的实际需求是有 DBA 级别的运维，也不在我的预期之内。毕竟在我预期目标之内的岗位薪资恐怕也招不到 DBA 级别的运维。

@privil

监控部分忘记写了，zabbix 还是会的，囧。

大多数情况下云平台提供的各种监控报警足够了，小公司自己搭建的动力不大。

而应用方面的监控之前公司后端开发人员完全没兴致，即便有安装一些收集数据的钩子也完全不看，而我只能看下执行时间的相关分析。

根本问题点还是数据库与现有需求不符、缺少一定数量服务器的生产环境实践，这两点是绕不开的，这点我还是清楚的。不过找工作嘛，就是要找到符合需求的坑，所以我的预期是偏向持续集成方向的。

虚拟化方面只是想说明还有些了解，至少对块存储、文存储，虚拟化有个基本理解，有时候也能解决一些问题。你要知道现在就算小公司也有要求有大规模 OpenStack 部署经验的。

PS：顺便吐槽一下，除开工具链差异，我真不觉的同样是关系型数据，差异会大到哪里去。

---

至于 JD Pass 的二三点嘛，这样说吧，所有 HR 都应该知道公开场合一定不能说“学历无用”，只能说“只要有能力，学历不是问题”但实际怎样做大家心知肚明。

二三点并不能说明什么实际意义，但是直接毫无修饰的写在 JD 上，只能说这公司真心有些地方有问题。

---

我（个人）理解运维的作用不是不让问题出现，而是如何正确的处理问题，让事情变得可控。毕竟只要有发生问题的可能，就一定会发生问题。

所以我要吐槽的是 JD 里各种要求“保障服务器 7x24 无故障运行”，再配上“领导交代的其他工作”，好像请个运维在公司就能让服务不出现问题，所以运维没事干就应该去做“其他工作”。

个人来说，已经没有多少时间能在基于这种思考模式下的公司待了。

@lgpqdwjh 卖得出去才能叫价格啊😂

不知道你当前的 sql 是怎么写的，感觉这种 100 分制后面也许会有问题，如果再加一个条件，比例要重新分配？业务代码相关部分都得改？


select a,b,c,d,e, sum(weights) from (
select a,b,c,d,e,1 as weights from table where a = '李四' and b = '女'
union all
select a,b,c,d,e,2 as weights from table where a = '李四' and c = '15611112345'
union all
select a,b,c,d,e,1 as weights from table where a = '李四' and d = '广西桂林'
union all
select a,b,c,d,e,1 as weights from table where a = '李四' and e = '[email protected]'
)
group by a,b,c,d,e
having sum(weights)>=3;

U 盘，不开玩笑。

@dbow

如果一个运维技术水平仅仅是“开发人员随便就能处理”的水平，那么被淘汰是必然。云平台普及，只是将这个水平线拉高罢了。

不出问题 => 招运维没用；会出问题 => 招运维没用。

嗯，完美逻辑。

不过开发人员随便搞搞就能解决的确实不需要专门的运维人员。

通常这类公司觉得要招运维的时候也是想着“不需要这个么一年只有几天工作的人”，所以薪资不会高，但是要求绝对不会低——毕竟要能解决开发人员解决不了的问题。

不过开出一个不高的薪资，能招到有能力解决“开发人员解决不了”的问题的运维人员吗？ ¯\_(ツ)_/¯

挖个大坑给楼主：hass.io

@Chingim 不不不，跟你说的没关系。

符合大多数中小公司理想型的运维人员：有大公司业务运维经验，拥有多种数据库的 DBA 水平，可以胜任网管工作，如果可以最好能加上司机或者电工。当然，小公司的运维工作又不重要，所以工资肯定不能比开发高吧。

而大公司招运维，就真的是招运维。

我也很绝望啊 ¯\_(ツ)_/¯

从我最近面试的情况看不会 ，很多中小公司技术 Leader 招人的回路是很清奇的。

日志分析人家考你 awk seq 用法，数据库要有各种集群操作实践 ，顺便优化 Oracal 和 MySQL，会用 OpenResty 来实现类似 WAF 的功能，最后还得处理办公室网络和桌面支持。

天使轮创业公司要求有大规模 OpenStack 集群经验，没管过几百台服务器都不好意思投简历。

大概是觉得云计算普及之后运维人员要求不高吧 ¯\_(ツ)_/¯

能输得起就折腾呗，还有啥好说的

@gt11799 学历还是很重要的，至少不会被 HR 卡，而且学历到底重不重要大家心知肚明 :doge:

虽然有心，但是以我目前的能力还不足以无视学历与年龄的弱点 _(´ཀ`」 ∠)_

只能说算是确定坚持写博客也能有点希望吧

其实我有点弄不明白，同样是无线通信，手机信号不好就知道一方面看基站覆盖一方面看手机基带。

换到 WiFi 上就只专注于怎么提高无线路由器的信号了 ¯\_(ツ)_/¯。

拉线是最优解，使用带 AP 功能的电力猫是次优解，使用无线中继是最次解。