アカウント名:
パスワード:
結局バッドノウハウ？の積み重ねじゃないかな？と思うんですよね。「理由わかんないけど、こういう手順を踏むと機能する」ってな感じの。
知人のWin Serverの管理者に聞いて「管理者名乗るんなら最低限知っておかないと」というノウハウを知っているかどうか、っていうのはどうでしょうかね？
・障害対応能力ログから対処法を検索できる能力と、サーバ構成からそれを直ぐにやって良いか等を検討できればいい。他はリソースの稼働状況などから状況を推察できればよい。UNIX障害の初動と左程変わらない。サードパーティ製アプリだと理由不足のまま、対処法だけ実施させる場合もあるのでそれができれば。（多分、原理がわからなくても手順どおりに対処できればOK、というのはこういうケースの事か？）過去に行った障害対応を２，３例くらい話して貰って検討してみる。
・サーバ運用能力WindowsServerあるいはMicroSoft製品の何で運用したいのか。それを明確にしないと募集しにくい。資格情報から読み取っても良いけど、実際に使えるかどうかは経歴を確認してみるしかない。Windows運用で特に自己解決しなければならないのは、データの入力形式や手順ミスの対処。現在行っている運用方法を軽く話して乗ってこれるかどうかで確認してみるなど。
・調整能力と決断力>たまに営業部門からWindowsでしか動作しないアプリケーションが回ってくることがある。Windowsは往々にして見ず知らずのパッケージを動かしたいといわれるケースがある。殆どブラックボックスで個人では保守しきれない。別の代替製品を提案できるか保守契約を結ぶか結ばないか、結ばない場合はどこまでしか保守できないかを明確に主張できる事。
正直いって、UNIXとWindowsの保守で大きく変わる部分は無いと思う。ただWindowsの場合はパッケージの種類（事務処理や監視カメラ等）が結構あり、ピンポイントで経験者が見つかり難いケースがある。Microsoft製品で使うミドルウェアを明確にして募集し、それ以外のアプリは保守を付ける、或いはアプリパッケージとミドルウェアが連携している場合はどちらも保守を付ける、(購買システムアプリとMSSQLが連動するので、結局テーブル設計もあわせてMSSQLも保守してもらうケース等がある）という、UNIXでは余り想定されなそうな変なケースがあり、それを理解してやれないと費用面の相談が厳しい。
そういう意味では技術力よりも調整や提案・説明が必要だった。Unixは深く掘り下げた技術者でないと使い物にならないだろうけど、利用するミドルの数は寧ろ限られてる気がする。
#基本はこの人の言うとおりだと思うのでここに。
例えば？
なんだか「とても詳しいのでバッドノウハウを知っている」のか「詳しくないので理解せずに手順だけ積み重ねてる」のかどっちなのかわからない。後者のようなWindows/Unix/etcに詳しくないけど手順だけ覚えて対処しちゃってる人は今回の「知識と情熱のある人材」じゃないのでは。
Unixも同じじゃね？
UNIX のノウハウにはちゃんと理由があって，管理者なrThe system is going down for halt NOW!
ふたつめにはちゃんと理由があるけれど、みっつめはおまじないだと思います。違った？
Linuxとか特にそういう感じですね。昔はUNIXは一度覚えたテクや設定ファイルは何年も使えたもんだったけど、Linuxで動きが速くなってからはバッドノウハウばかりになったように思う。きっちりまとめたサイトの情報では古すぎて、取り留めの無いBlogの方が参考になるみたいに。
ごめんなさい。私、その「ほとんどゼロ」の人です。追っかけられるソースがあるだけ幸せ。そんなゼロに近いですかね？周りの連中のレベルなのかもしれませんが、逆にソース公開の物で「よくわかんないけどこうやったら動いちゃった」なんて報告上げたら、失笑ものです。もちろんLinux/オープンソースの分野でも「よくわかんないけど・・・」が無いわけではありませんが。
かなりな極論ですが、ソース読めないヤツがUNIXの管理者名乗っちゃいけない（後Bug情報を読めるくらいの英語力無いヤツもアウト）。エラーメッセージ出てるのに、Googleにコピペするくらいのこともできないヤツが管理者名乗るのを見ると・・・無駄金払ってるな、とか思います。
やっぱりこういう種類のバカだったか。あんたそもそもの問いに答える知識ないだろ。全然関係ない自慢はよそでやってろ。
> ソースの中まで見て動作を把握してる人間なんて，割合でいえばほとんどゼロに近い．というよりも、管理という観点からは、(バイナリの)ソースまでは見なくていいことがほとんどだし。テキストの設定ファイルを(テキストエディタで見られる)スクリプトで見てわかる部分が多いしね。まあ、よく知らないけどSolarisなんかは10辺りからそういうことができなくなってるらしいけど。
ついでにいうと、バッドノウハウってのは、ドキュメントに書いてあるのと違う動作がどのくらいあるか、ってのがかなり多いと思うけど。このビルドからはドキュメント通りになったとかその逆とか。
> 「『管理者名乗るんなら最低限知っておかないと』というノウハウ」を教えてくれ，そうなの？自分が管理者になりたいという話じゃなく、管理者を選びたい、ということだよね。
>↓これ，UNIX管理者にありがちなWindows見下しの典型にしか見えない…>>> 結局バッドノウハウ？の積み重ねじゃないかな？と思うんですよね。「理由わかんないけど、こういう手順を踏むと機能する」ってな感じの。
いや、> by gonta (11642) on 2012年09月01日 13時39分 (#2223112)が偏ってるだけで、UNIX管理者だからといってこんな変な発想もってるわけではない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
Win Serverって (スコア:3, 参考になる)
結局バッドノウハウ？の積み重ねじゃないかな？と思うんですよね。「理由わかんないけど、こういう手順を踏むと機能する」ってな感じの。
知人のWin Serverの管理者に聞いて「管理者名乗るんなら最低限知っておかないと」というノウハウを知っているかどうか、っていうのはどうでしょうかね？
-- gonta --
"May Macintosh be with you"
Re:Win Serverって (スコア:2)
・障害対応能力
ログから対処法を検索できる能力と、サーバ構成からそれを直ぐにやって良いか等を検討できればいい。
他はリソースの稼働状況などから状況を推察できればよい。UNIX障害の初動と左程変わらない。
サードパーティ製アプリだと理由不足のまま、対処法だけ実施させる場合もあるのでそれができれば。
（多分、原理がわからなくても手順どおりに対処できればOK、というのはこういうケースの事か？）
過去に行った障害対応を２，３例くらい話して貰って検討してみる。
・サーバ運用能力
WindowsServerあるいはMicroSoft製品の何で運用したいのか。それを明確にしないと募集しにくい。
資格情報から読み取っても良いけど、実際に使えるかどうかは経歴を確認してみるしかない。
Windows運用で特に自己解決しなければならないのは、データの入力形式や手順ミスの対処。
現在行っている運用方法を軽く話して乗ってこれるかどうかで確認してみるなど。
・調整能力と決断力
>たまに営業部門からWindowsでしか動作しないアプリケーションが回ってくることがある。
Windowsは往々にして見ず知らずのパッケージを動かしたいといわれるケースがある。
殆どブラックボックスで個人では保守しきれない。別の代替製品を提案できるか
保守契約を結ぶか結ばないか、結ばない場合はどこまでしか保守できないかを明確に主張できる事。
正直いって、UNIXとWindowsの保守で大きく変わる部分は無いと思う。
ただWindowsの場合はパッケージの種類（事務処理や監視カメラ等）が結構あり、ピンポイントで経験者が見つかり難いケースがある。
Microsoft製品で使うミドルウェアを明確にして募集し、それ以外のアプリは保守を付ける、
或いはアプリパッケージとミドルウェアが連携している場合はどちらも保守を付ける、
(購買システムアプリとMSSQLが連動するので、結局テーブル設計もあわせてMSSQLも保守してもらうケース等がある）
という、UNIXでは余り想定されなそうな変なケースがあり、それを理解してやれないと費用面の相談が厳しい。
そういう意味では技術力よりも調整や提案・説明が必要だった。
Unixは深く掘り下げた技術者でないと使い物にならないだろうけど、利用するミドルの数は寧ろ限られてる気がする。
#基本はこの人の言うとおりだと思うのでここに。
Re:Win Serverって (スコア:1)
例えば？
なんだか「とても詳しいのでバッドノウハウを知っている」のか「詳しくないので理解せずに手順だけ積み重ねてる」のかどっちなのかわからない。
後者のようなWindows/Unix/etcに詳しくないけど手順だけ覚えて対処しちゃってる人は今回の「知識と情熱のある人材」じゃないのでは。
Re:Win Serverって (スコア:1)
Unixも同じじゃね？
sync; sync; sync; halt; (スコア:0)
UNIX のノウハウにはちゃんと理由があって，管理者なrThe system is going down for halt NOW!
Re:sync; sync; sync; halt; (スコア:1)
ふたつめにはちゃんと理由があるけれど、みっつめはおまじないだと思います。違った？
Re: (スコア:0)
Linuxとか特にそういう感じですね。
昔はUNIXは一度覚えたテクや設定ファイルは何年も使えたもんだったけど、Linuxで動きが速くなってからはバッドノウハウばかりになったように思う。
きっちりまとめたサイトの情報では古すぎて、取り留めの無いBlogの方が参考になるみたいに。
Re:Win Serverって (スコア:2)
ごめんなさい。私、その「ほとんどゼロ」の人です。追っかけられるソースがあるだけ幸せ。そんなゼロに近いですかね？周りの連中のレベルなのかもしれませんが、逆にソース公開の物で「よくわかんないけどこうやったら動いちゃった」なんて報告上げたら、失笑ものです。もちろんLinux/オープンソースの分野でも「よくわかんないけど・・・」が無いわけではありませんが。
かなりな極論ですが、ソース読めないヤツがUNIXの管理者名乗っちゃいけない（後Bug情報を読めるくらいの英語力無いヤツもアウト）。エラーメッセージ出てるのに、Googleにコピペするくらいのこともできないヤツが管理者名乗るのを見ると・・・無駄金払ってるな、とか思います。
-- gonta --
"May Macintosh be with you"
Re: (スコア:0)
やっぱりこういう種類のバカだったか。
あんたそもそもの問いに答える知識ないだろ。全然関係ない自慢はよそでやってろ。
Re: (スコア:0)
> ソースの中まで見て動作を把握してる人間なんて，割合でいえばほとんどゼロに近い．
というよりも、管理という観点からは、(バイナリの)ソースまでは見なくていいことがほとんどだし。
テキストの設定ファイルを(テキストエディタで見られる)スクリプトで見てわかる部分が多いしね。
まあ、よく知らないけどSolarisなんかは10辺りからそういうことができなくなってるらしいけど。
ついでにいうと、バッドノウハウってのは、ドキュメントに書いてあるのと違う動作がどのくらいあるか、ってのがかなり多いと思うけど。このビルドからはドキュメント通りになったとかその逆とか。
> 「『管理者名乗るんなら最低限知っておかないと』というノウハウ」を教えてくれ，
そうなの？
自分が管理者になりたいという話じゃなく、管理者を選びたい、ということだよね。
Re: (スコア:0)
>↓これ，UNIX管理者にありがちなWindows見下しの典型にしか見えない…
>>> 結局バッドノウハウ？の積み重ねじゃないかな？と思うんですよね。「理由わかんないけど、こういう手順を踏むと機能する」ってな感じの。
いや、
> by gonta (11642) on 2012年09月01日 13時39分 (#2223112)
が偏ってるだけで、UNIX管理者だからといってこんな変な発想もってるわけではない。