インフラ主要是做什么?

MMM2821209

哈哈`~~~~有意思啊

MMM2821209

网管也不错哦

ku6

前半部分说的很有道理
但是后办部分就不能苟同了
下游的インフラ 是照着手顺书办事
一般称为CE
上游的インフラ就是写手顺书的了 称为SE
ORACLE的安装，硬盘的设定，备份  等等  看似
厂家都给了操作说明什么 ...
小兽 发表于 2010-1-14 00:26

学习了，看来不是什么容易的活啊，怪不得公司面试那么多人还是没定下来！

tlele

在日本所看到的インフラ主要大体上可以理解成网络基础设施相关的内容，也就有人说得基盤。

可是，对于一个企业来说，基盤的范围就广很多。
比如说，所有的支持企业业务流程的信息系统都是基盤。
包括，网络，服务器，以及网络和服务器上层运营的应用程序。
如：ERP，CRM，财务系统，相关的数据库系统，以及相关的信息系统安全等等。

另一方，范围这么广，一个人或者少部分人就很少能够胜任这样的工作。
这就要从部门来看，比如说支持和运营维护部门的，大多是情报信息部门。
部门里面又分，网络服务器，软件数据库，信息安全小组等。

上面的分类也有些暧昧，因为网络是网络，服务器是服务器，软件是软件，DB是DB，安全又是安全。
并且，网络和服务器相关，和安全又相关。程序和数据库和安全也相关和网络又相关联。
从技术角度来分，一个区域是一个区域的。可信息系统部门是用钱的东西，人员上没有那么葱郁。
所以，很多情况下企业都喜欢要多才能的人，这样可以最小的人数来支持大多数的企业信息系统。

可从欧美的和一些上市企业来看，大多数都是有业务范围，职能分工。
也就是说，你被招聘进来做什么，就做什么。除非企业有很好的人才管理制度，可以根据个人的要求，在工作中调换岗位。
大多数情况下是不可能的，特别是日本的企业。

我不知道我在说什么，可你听到インフラ这样的字样的时候，大多是网管和服务器管理员，可以断定的是，肯定是信息系统部门的一个角色。
如果企业规模小，那么你将从事多任务，使用不同的技术，仅似乎全能。
如果企业规模很大，那么你将从事专项的任务，所以用专门的技术，仅似乎技术员工。
这样看来，你所需要的技术是不一样的。这在面试的时候是一个突破点。

在我个人看来，无论是大企业还是小企业，专项技能和办公自动化意识和能力的拥有者都将是强手的，特别是现在大家钱包都很紧的时候。
也就是说，拥有软件开发才能的人，又能做服务器网络维护的人，肯定是强手的。
也不一定就是绝对的哦！

更高端的人才，那就是内部控制，SOX，ISMS，信息系统审计，ISO，BCM相关技能的持有者。
很玄哦！
可现在的时代，不是专才的人吃的开的时代了，复合型人才和发展空间更大的人才更吃香的时代咯！

说那么多，没用。
看到インフラ大体理解成，YAMAHA，Juniper，Cisco，Linux，Windows Server，Oracle这样的词汇和技术，是没有错的。

我又不是全能，怎么会那么多呢！
没关系，你只要过了面试那一关，就OK了。
反正，做事情的人，肯定不止你一个，你是部门，小组成员中的一员。
这就要求你有很强的沟通和调节能力，可不是编码和做测试那么简单。
部门人员少的时候，你必须协调各部门来解决一个问题，特别是那种半成品和多半成品的信息系统企业运用的情况下。

インフラ技能要求要高一些，但工资未必就比开发高。
可乐趣恐怕要比做测试和编码要多很多，这是我个人的体会。

bigbug_008

在日本所看到的インフラ主要大体上可以理解成网络基础设施相关的内容，也就有人说得基盤。

可是，对于一个企业来说，基盤的范围就广很多。
比如说，所有的支持企业业务流程的信息系统都是基盤。
包括，网络，服 ...
tlele 发表于 2010-1-16 01:45

为打心底为了这么多文字致敬~~~

tlele

本来扯皮捣蛋的内容，被我写的有点儿认真了。

bigbug_008

本来扯皮捣蛋的内容，被我写的有点儿认真了。
tlele 发表于 2010-1-16 10:59

主要是这边99%都是搞应用层的人，对这些概念淡薄是很自然的

beldandy

インフラ 工资高不高主要看工作性质，是设计还是保守。
做设计的时给基本在3000－4000，时给5000 的offer我也见过。保守时给好像都是2000－2500
服务器我不太熟悉，但是做网络的项目，灵活性很大，对工程师的技术要求比coding要高。
而且压力很大，做网络有很多不可预见的问题，需要很好的沟通能力和主动性，导致对语言能力要求也高。

日本做インフラ 中国人少的主要原因还是：在国内做这行的人基本从英语资料自学起来的，一般人不会特地跑来日本混。

beldandy

做网络和服务器的设计项目成就感很大，这种项目一般很难像汽车流水线一样，把工作平均分割给一组人分别完成。
项目的成功主要靠PM和SE的个人能力，有点“个人英雄主义”，懂的人来1个就能全部搞定，不懂的人来100个都没用。这点和coding多少有些不同。
所以每次TEAM REVIEW都要和其他人讲故事一般介绍我为啥这么设计，可是效果有限。
要别人短时间马上跟上设计者本人的思路很难。