V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  tomczhen  ›  全部回复第 56 页 / 共 81 页
回复总数  1604
1 ... 52  53  54  55  56  57  58  59  60  61 ... 81  
2017-12-17 20:01:03 +08:00
回复了 cnbattle 创建的主题 程序员 日活 3K 左右的 app,后端有必要上 Java 吗?
已经上线的项目,就算能解决初期造遗留的问题也需要很大的代价——技术债务越晚偿还代价越高,根本不是多个岗位能简单解决的事。

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

说白了就是“短期高估”——期望一个运维 /DBA 能解决所有问题;“长期低估”——运维 /DBA 又没多少工作量,专门请一个太浪费,让开发顺便干了就行。
2017-12-16 13:35:29 +08:00
回复了 Moorj 创建的主题 问与答 NAS 用全 SSD 组阵列是一种什么样的体验?
有万兆网络才能体验了,虽然价格还是贵,不过明年家用级万兆电口产品应该会开始铺了。

阵列不等于备份,对存储系统而言只要性能有需要,硬盘只是消耗品。
2017-12-15 21:25:01 +08:00
回复了 derek80 创建的主题 问与答 多区域少量 docker 服务怎么管理比较好?
看看 daocloud 的免费版本能不能满足,不行的话只能由简单到复杂方案自己实践评估一下了。
新生事物在早期本身就是有很多问题的,Docker 确实解决不了所有问题,有自身的缺点,也会带来新的问题,不过搞软件工程应该知道的第一件事不就是“没有银弹”吗?

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

那些高大上的企业的容器实践分享可是实际存在的,自私的讲,出于丰富自身技术阅历考虑,也得尝试一下吧?
@gdtv 任何事情都是有代价的。

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

每个项目、每个人所衡量的收益、成本不同,没必要拿来作为唯一准则。
小公司不都是开发“顺便”解决掉这个问题么?

之前待的公司后台要我把服务器换成 win7 试试你能信?
既然不是为了 GPIO 还是买 x86 平台比较好一些。
先退款呗,还能怎样。
2017-12-13 11:15:49 +08:00
回复了 leon0918 创建的主题 互联网 简书 CEO 这表态,怎么看?
考虑到屁股所处的位置,这样的言论是没有问题的。

选择自由的权利意味着也要承受自由权利的代价。
2017-12-13 00:02:11 +08:00
回复了 Les1ie 创建的主题 Docker docker 官方镜像很多用 debian 的?
Alpine 有个蛋疼的地方,Android 编译用到的 aapt,老点版本是 32 位的,新版本是 64 位的,我没找到可以同时可运行的办法。
https://www.v2ex.com/t/323425

使用 DNS 认证方式即可
2017-12-11 18:49:56 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@x18960

不不,我不是大佬。

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

静态页还好,动态信息请求打死数据库什么的才叫绝望。
2017-12-11 17:55:23 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@x18960

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

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

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

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

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

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

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

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

PS:如果真的精于安全攻防的话我(个人)会选择去干灰产或者找家大公司洗白¯\_(ツ)_/¯。
2017-12-11 12:43:10 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@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 是业务合适的教育、医疗行业。

虽然目标明确是好事,不过这也提高了我就业的难度,现在这个时间点要找到一家规模合适又符合技术栈的公司愿意招我入职还是比较难的。
2017-12-10 23:35:54 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@402124773

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

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

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

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

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

@greyterry

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

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

讲实话,个人觉得中级以上有开发能力的大多数应该会选择转成开发——毕竟可以少操心很多事,而且薪水也更高。
2017-12-10 15:55:47 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@privil

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

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

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

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

反过来讲,如果一个公司岗位的实际需求是有 DBA 级别的运维,也不在我的预期之内。毕竟在我预期目标之内的岗位薪资恐怕也招不到 DBA 级别的运维。
2017-12-10 15:23:53 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@privil

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

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

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

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

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

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

---

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

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

---

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

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

个人来说,已经没有多少时间能在基于这种思考模式下的公司待了。
2017-12-09 23:55:39 +08:00
回复了 tomczhen 创建的主题 求职 [深圳] - 运维相关岗位 - 顺便求点评
@lgpqdwjh 卖得出去才能叫价格啊😂
2017-12-04 12:28:43 +08:00
回复了 forkme 创建的主题 程序员 千万级数据库记录模糊匹配效率问题
不知道你当前的 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;
2017-11-28 17:31:51 +08:00
回复了 digimoon 创建的主题 问与答 hyper-v Linux 虚拟机与宿主机的文件交换有什么方案?
U 盘,不开玩笑。
1 ... 52  53  54  55  56  57  58  59  60  61 ... 81  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2598 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 34ms · UTC 14:19 · PVG 22:19 · LAX 07:19 · JFK 10:19
Developed with CodeLauncher
♥ Do have faith in what you're doing.