はてなキーワード: slaとは
某ソシャゲがトラブったことをきっかけに、クラウドエアプ勢の大先生だちが珍説をぶち上げてる
曰く、「AWSはクラウドなんだからハードウェア障害なんて起こらない」「仮にあったとしたら世界中が大騒ぎじゃん」みたいな理屈らしい
物理ホストのハードウェア障害でインスタンスが立ち上がらないとか普通にあるし、1個や2個物理ホストが死んだくらいでいちいちリージョンのステータスすら変更しねーよ
彼らが使ってたのはEC2だろうし、そこのSLAをもう一度読んだ方がいい。そして、もし本当にITエンジニアで、AWSにハードウェア障害なんてないなんて言ってる人は、頼むから引退してくれ。システム作るレベルにいないから。
http://ascii.jp/elem/000/001/162/1162199/
英語学習に関しては自分も成功体験があり、高3の時はセンター模試40点から半年で182点まであげたことがある。この記事内で紹介している体験ではなく脳科学的なアプローチであるSLAだが、高3で受験勉強を始めるにあたってボトルネックだった英語をあげるためにいろいろリサーチした中で出会った英語学習の本で同じメソッドが紹介されていた。御歳80歳くらいの同時通訳者が戦時中に中学校の英語教材を音読によって全部暗記したら米軍の言葉が聞き取れるようになった経験から、英語学習は中学レベルの教科書を音読するのがいいというメソッドだ。これを僕は愚直にやり、英単語を日本語に訳さなくても頭に意味がイメージできる状態にする→文章を音読して英語の文のままイメージできるようなになる(同時に英語のリズムを覚える) これを繰り返し、普通の市販の教材を暗記しまくったら解法テクニックは覚えなくてもセンター過去問で10分あまって90%の得点率になった(本番はメンタルが弱いので75%ぐらいしか取れなかったがw)。また大学3年の時は就活に備えてTOEICの勉強をしたときは、脳のワーキングメモリの処理の概念は理解していたので、TOEIC用の単語を覚える(無意識に呼吸レベルになるまで)→長文を音読するで英語学習の感覚を取り戻しつつ語彙を増やし、TOEIC用の対策本で文法問題は○×△法+エビングハウスの忘却曲線にそった反復学習で1回目の暗記→9時間後(または翌日)→1週後の3回くりかえすことで長期記憶に定着。これの勉強法で、3週間で460→645点であがった。そこで自分で考えて短期的に結果を出す経験を得たことに満足してまいその後の学習はしなかったがw、この記事で書いてあることは自分の経験則としてすごくよくわかる。
こうしてみるとグリットが足らない人生だね、筋はいいことはできてるし自分で考えて行動して結果を出すことも部分的にはできているけど一番のゴールは達成できていない。
中学校最初のテストでたまたま数学学年一位で部活の先輩とかいろんな先生にちやほやされて自分は本気だせば勉強できるとか勘違いして、授業以外ではほぼ勉強せずにトータル学年10位-20位くらいをうろうろ、3年最後のテストで一位とってやろうと思って勉強するも4位どまりで一位は無理か〜と思ったが、もっと前のテストから1位を狙っていれば学習のPDCA回せたと思うのにそんなことは気がつかず。
高校も県外に引越しのタイミングなので志望校選びを家から一番近い高校にして入ったが、入試の開示されたあの点数なら県1-3の高校合格ラインだったのに思考停止してた。
高校は勉強せずにテストで0点とかとってるのがクラスで目立ってたのがウケてたと思ってたので二年間勉強せず学年ビリとったり、英語数学国語で1とって進級できない人向けの試験受けることになってる時でも、本気出せばいけると思っていたw 今思うとこの時に勉強を通じて思考力や集中力、自分なりの課題解決のプロセスを確率する訓練を積んでいないのがいまに悪い意味で繋がっていると感じる笑
受験勉強も他の人からするととても伸びて結局国立大受かったのに、もっと上いけるとか思って浪人して堕落し結局一朗ニッコマでしょ、予備校入りたての時は地理は東大コースで京大の過去問といて他の生徒よりいい成績出したりしてたのに、夏になぜか世界史に変えてそこからめんどくさくなってセンター本番50点でまた地理にもどすという超迷走かましてた
そこで自分で浪人を選んだのに結果がでなかったのでネガティブになり消極的になったんだ、思い出した笑
つまり自信を失ってるのは自分で選んだ選択で結果がでなかったからで、自分への信頼がないわけで、そこを改めてとりもどさないと一生このままでしょ
やろう、ポテンシャルはあるはず、足りないのはやりきる力
当方は情報システム部に属しており、社内のインフラのサポートをしている。
無線LANのアクセスポイントは、同一フロアで全部で4台あり、全て固定チャンネル設定をして運用している。
4台のウチの2台ー3台が、この様なログを履いてチャンネルが変わってしまう現象に襲われている。
2016/07/22 16:15:13: [802.11] Radar found on channel 64
2016/07/22 16:15:13: [802.11] Changing to channel 40
2016/07/22 16:15:13: [802.11] Changing to channel 40 (5200 MHz) chanStart 64
Channel 40 に切り替わる設定はどこにも記述ないので、どこから出てきた?と。
自動でチャンネルが変わる記述は無いと思っているのだが、皆目検討つかない。
Configurationの読み込み直しのためにRestartも何回もした。
Firamwareは、バージョン:Rev.12.00.16 最新ではないが、最新までのRelease notesはチェック済みで該当してそうなものはなし。
困り果てて、バグかと思いY社サポートに問合せを入れるも1週間連絡がない。
1)受付番号を聞かれ、返答すると、そのような問合せは無いと当初言われる。
→これサポートで問合せ受領して、勝手にCloseしてんじゃねーかな。
先日は1両日には返答頂いておりましたが、最近は問合せが立て込んでいる。という事でしょうか?と質問するも
→「そんな事は無いが、返答できない。」との事。
→「返答できない。」との事。
こんな感じなので、解決時期の見込みもたてられない。
3)とても困っているので対応の優先度を上げてもらえないか?とお願いするも断られる。
まぁ、こちらとしてもY社の機器を購入すると付随する保守サービスに加入しているだけで、Additionalで費用を負担しているワケでもない。
また、Y社のサポートセンターにSLAが定義されていないので、こちらとしては明確に期限を要求できるワケでもない。
ぶっちゃけ彼らが返答に誠意を見せない。と、言われてしまっては、結局何やっても無駄なんだよね。
サポートの出来によって、その製品を使い続けるかどうかの判断になるのにね。
世の中的には、チャットサポートがデファクトになりつつあり、そのアジリティに比べると旧態依然した大企業のサポートだな。と思ったわけで
全てを悟った私はおとなしく他社製品でリプレースすることを決めた。
#もし、原因のヒントがあれば教えて頂ければ幸いですw
ーーー追記ーーーー
DFS機能により使用しているチャンネルが変更される時、選択されるチャンネルの範囲を指定します。と、あり。
この定義を全て削除していて、実質切り替えできない認識でいた。
Configには表示されないが、暗黙デフォ値(airlink channel range dfs all)が使われている理解で良いのかな。
とはいえ、切り替わっても、使ってないチャンネルの中から定義して上げれば良いことに気づいたのでそれで運用しようと思います。
酔っぱらってる。すまん。2時間ぐらいで考えたもので穴も多い。みんなで作りあげてほしい。
昨今のソーシャルゲームで一番面倒くさいのは「私のソーシャルゲームがこんな確率で外れるわけない!」というクレームだったりする。
現場にいる人間として、クレームで一番面倒くさいのはこれなんだ。回答のしようがないし、お客様に納得していただける返事がほぼできない。
例えば「10%で獲得できる」ものでも、1回で獲得できるお客様もいるし、100回やっても獲得できないお客様もいる。システムに問い合わせるとこればかりはランダムで無理なんだそうだ。
システムにはあまり詳しくないのだが、オンラインカジノ(調べたのは主にポーカー。ポーカースターズというのが大手らしい)では、ソースがしっかり公開されており、該当ハンドでのシード(このランダム文字列をそのソースに与えるとと同じ結果になる)が公開されていることにより、意図的な操作が行われていないのを示すらしい。
これと同じことをソーシャルゲームでも行えれば問題が減るのではないのか。
私が作ったサービスを介して、ガチャなどランダム要素があるもののランダム性を保証する。
ランダム性はオープンソース+シード方式で保証(第三者が検証可能なものにする)する。
どちらのプランもフル機能を利用できるが、無料プランでのアルゴリズム及びプランデータは全て匿名なものにして大手データプロバイダーに売る。
有料プランにおいては全てのデータがどんな形でも外に出ることはない。SLAも設定する。課金モデルはトランザクション単位(このアプリケーションではおそらく抽選単位になる)。
オープンソースによる信頼性の担保に対して大手企業がどんな反応を示すか?(さすがに今更…)
寝ます
去年平成24年春期プロジェクトマネージャー試験を一発合格したので私と同じ非リア充社会人向けに方法を書く。エリート野郎、社会的マッチョ、イケメン、リア充の方はこの先お断りする。
①平日の朝を制する
朝起きるのはどうってことない。前の日に1時くらいまでに寝れば5時間くらい寝れる。余裕。
淡々と会社のプリンタで過去問10年分の過去問をコピーし、ファイリングして、朝の限られた時間で
解ける問題を解く。あんまり堂々とやらない。こそこそ仕事しているフリをしてやる。
幸い飲みに行って夜更かししちゃったーみたいなことが皆無なので規則正しく生活できている。
よく言えば効率化する。悪く言えば手の抜き方を覚える。
結果はこれまでと変わらず出す。(これ大事)
残業も変わらずやる。
私は昼休み、時には仕事中に隙を見て試験勉強やってた。文章書くフリして論文のモジュールを淡々と書いていた。
仕事の息抜きにタバコを吸いに行くひと同様、私は息抜きにちょろっと勉強した。
上司に見つかったら言い訳しろ、キリッ。覚悟を決めてぬかりなくやってほしい。
土曜の朝の喫茶店は異常なほど快適だ。世間は土曜日の朝くらい一息つきたがるからな。空いているぜー。窓際の端っこの最高の席がとれるぜ。広々ゆったり勉強ができるぜ。
休日の朝起きるのがつらいって?休日を無為に過ごしたときの情けない気持ちを味わうよりか
ちょっと平日と同じように起きるくらいどうってことない。
朝起きることくらいどうってことない。余裕。
自分は基本的に5時間寝れば十分という感覚を持っているので1時に寝ても6時間は確保できる。
十分。十分。
で、喫茶店で13時くらいまで粘る。集中の波はあるが4〜5時間はそこにいるってことを目標にがんばる。
たまに音楽聞いたり、違うことやったりしてもよい。とにかく時間で目安を作る。
土曜日の勉強は昼いっぱいまでやって以上終わり。あとは好きなことして過ごす。
日曜の夜の喫茶店は異常なほど快適だ。世間は日曜日の夜に一息つきたがるからな。空いてるぜー。またしてもいい席ゲットできるぜー。
日曜日の夜をエンジョイしたいって?大丈夫、君はおそらく友達がほぼいないだろう(私もだ)。何も心配することはない、無為に一人で過ごす日曜日が充実の日曜日になるだけだ。
で、喫茶店には23時の閉店を目指してがんばる。
明日の仕事のことが気になったりするだろうが、気になれば休憩がわりにTODOリストでも作って
1週間のやるべきことを整理すればよい。
以上が黄金の鉄則だ。
みよちゃん(みよしやすゆき)という先生を信じる。以上。ステマでもなんでもない、この人の作る参考書は魂というか怨念がこもっている。自分の頭で咀嚼して教材を作っている。私はみよちゃんみたいな人間がもっともっと成功して名声を手に入れてほしいと思う。
以下に私が使った教材を挙げる。
・みよちゃんのH24年度向け参考書1冊(神の書)
・論文対策用の論文サンプルがいっぱい入っている少し大きめの白いカバーの本1冊
・過去問全部(IPAから無料で落とせる。全部印刷してファイリングする)
・ポケットスタディPM(午前対策用、直前に流し見ただけだが)
まずはじめにみよちゃん本を中心にPMBOKの9つの領域で分けて
例えば品質管理ではSLAの確認、品質計画、品質管理で・・・・というように
進捗遅れた場合はこれとこれとこれ、品質悪いときの対策はこれとこれとこれ、みたいなことを
虎の巻は常に持ち歩き常に更新して常にプリントアウトして、過去問といて行く中で覚えときたいものが
最終的には虎の巻はワードで20ページくらいになった。過去問は10年分くらいを一通り答え見ながら
といた。過去問はまともにやると時間がかかりすぎるので答え見ながらその問題のパターンを覚えて即時虎の巻に
フィードバックするのがよい。答え見てよいから数をこなしパターンを覚えよう。
論文対策は実は虎の巻編集以外にやっていない。一回も論文書かずに試験受けた。受かった。
これは虎の巻に論文を意識した「対策モジュール」を何パターンも書いていたから試験当日でも
そのモジュールの組み合わせだけで解けた。論文の構成とかの具体的指南はみよちゃんの言ってることを参考にした。
あとは実務で経験している「プロジェクトあるある」を臨場感を演出しながら散りばめて書けばよい。
まとめると私の勉強は「みよちゃんと過去問を参考に自分用のPM虎の巻を作った」である。これ以外やってない。
論文書いたことなかったが試験のときはわき上がるように書けた。書き尽くせた。家に帰ると全身が筋肉痛になり知恵熱みたいなもんが出た。
自分用の虎の巻を書くことで自分の頭の中にPMBOK体系が再構築される。
人のやつを流し見ても意味がない。自分の脳にフィットした自分のものを作らなければきっと覚えられないだろう。
(もし参考になるのなら私の虎の巻を公開しますが、需要あるかな。)
自分の頭でプロジェクト知識体系を咀嚼する。これがポイント。下手に暗記しようとしたらダメ。
以上です。よかったら参考にしてください。
仕事中に勉強すんなとか、仕事に集中しろとか喫茶店で勉強すんなボケとか言われるかもしれないが
これは自分の人生を自分で選ぶというか、自分は経歴がクズなもんでもっともっと上に上がりたいという
意識が強く、いつもこのままじゃだめだとマイナーリーグでやるよりいつかメジャーに上がりたいという
こんな人生他人から見たらつまらないのかもしれないが(いや、私から見ても確かにつまらん)、とにかく上に上に行きたいという思いで
いつも家路に着く途中の高層マンションを見上げながらいつかここに住みたいと強く思いながら
忸怩たる思いを抱えながら勉強するしか道はないという思いで土日祝日勉強に費やして平日仕事して生きている。
仕事もがんばる、勉強もがんばる、家族も大切にする、そして上に行く。
でもこんな私でもたまには今日は勉強したくないなとか1週間モチベーションが下がりっぱなしで何もしなかったとかざらにあるのだけど
そんな時はいつも自分の「なぜ勉強しようと思ったのか」に立ち返るといいと思う。強く思いを噛み締める。
そしてまた明日から本気だす、キリッ、で十分リカバリーできる。
勉強道具持って喫茶店の席に座れば必ずリカバリーできる。勉強のモチベーションはいつだって必ず復活する。
そしてそして最終的に試験の結果なんて水物なので結果は必ずしもいい方向に出ないかもしれない、だけど忙しい中で一生懸命勉強したならば一生懸命やったこと自体には満足してほしい。ダメだったらまた立ち上がってまた挑戦すればいい。立ち上がるのはしんどいんだけどもう一度立ち上がるしか道はない。
私も引き続き頑張る。皆さんも頑張ってください。
まぁ、色々な幸運?が重なってそこまでデカイ障害にはなっていないように見える今回PS3の閏年問題。
しかし、SCEはこれから対処しなければならない問題があり、企業の障害対策の観点から言えばここからが本番だ。
一応サービス業に従事するものとして、勉強を兼ねて緊急度別にどんな問題を解決しなければならないのか挙げておこうと思う。
まぁ、コレがぶっちゃけ一番でかいよね。なんせ金取ってるし。
全部の商品を調べたわけではないが、基本72時間単位で課金をしている事から見て、今回の障害で72時間中最大24時間、
実に契約期間の1/3も利用不可の状態にしてしまったわけで、このまま白を切るワケにはイカンよね。
何らかの保証が必要でしょう。
PSNの利用規約にざっと目を通したところ、「ナニが起こっても基本的にSCEに責任ありません」とか、
「最悪保証する場合も購入金額を超える保証はしません」というこの手のサービスによくある記述しか無いため
どのような保証がなされるのかは現段階で不明。
せめて障害期間に被ったレンタル契約に関しては全額返金するぐらいの対応をすれば、
多少の痛手と引換に今後のブランドへの信頼感を得られるのではないでしょうか。
つか、何の根拠も無い俺の個人的な予想では、痛手ですら無い額だと思うけどね。
上とまとめても良かったんだけど、ビデオレンタルは利用期間が短く障害の影響がほかと比べて甚大すぎる為切り分けました。
その他課金サービスに関しては、殆どがSCEを通して他の企業が提供しているサービスなので、企業間契約でSLAがどうなっているか
によるのですが、ぶっちゃけその辺の契約なんて分かる訳ないので割愛。まぁ、丸一日商売の邪魔したわけなので、
お咎めなしってワケには行かないでしょうね。お偉方が菓子折り持って謝罪行脚程度で済めばいいんですが。
ウチのPS3は運良く障害期間に全く利用しなかったのと、まだ情報を集めてないのでコレがどうなったか分かってないんですが、
報告にはセーブデータがイカれた、テーマがイカれた、トロフィーデータが消えた等の報告が上がってました。
トロフィーは同期してない分は復旧無理だろうけど、ぶっちゃけ他に比べたら緊急度低すぎてココに含めなくても良かったぐらいですが
一応おなじデータって分類なのまとめました。
購入したDLCについてはアカウント情報さえ手元にあれば購入履歴から再度DLし直せばいいので、謝罪文のみですむ場合がほとんどでしょう。
ただ、セーブデータに関しては対応を間違うと今後の商売に響きかねないので注意が必要でしょう。
とはいえ、たぶん最終的には諦めてもらうしかないんですけどね。
セーブデータに関しては、発売当初誰とでもセーブデータの交換がネットを通じて出来ると言う恐ろしいまでのオープンな姿勢から一変、
オンラインゲームが増えてきたこともあり管理が非常に厳重となっております。万が一破損フラグを立てるだけでデータはそのまま残っていた場合でも
コレをパッチ等で復旧させるのは、技術的には簡単でもPSNの今後を考えると絶対に行えない対処です。
なぜかというと、今年に入ってPS3のファームウェアが完全にクラックされてしまった可能性があるからです。
iphoneのJailBreak等で名を馳せたとあるクラッカーが年末年始あたりからPS3に手を出し、実質5週間で完全にクラックした、という報告を自身のサイトで
発表したと言うニュースがありました。コレがすぐ割れにつながるわけではないですが、最高レベルのシステム権限すら握れてしまうらしく、事実であるなら
破損フラグ除去パッチなど、どう考えても配信できる訳ない。手がかり無しで自体を把握しなければならないクラッカーにわざわざヒントを与えることになりかねず
泥棒に追い銭やるようなもんだからです。
というわけで、誤って起動してデータが破損してしまった方は残念ですが諦めた方が良さそうな感じ。
オンラインに関係ないゲームなどは多少融通が効くかもしれないですが、そのへんはゲームタイトルによるのかもしれません。
まぁ、緊急度ゼロでも良かったんだけどwww
コレはぶっちゃけどうでもいい。大した影響ないから。外野が多少喚いたところで今のPS3の勢いなら何の影響もないでしょう。
長々と書いたけど、こんなもんじゃなかろうか?どう対応するのか見ものです。
何もしないってことは.....流石にないよね?特に課金関連。
まぁ、他人事なので興味深く見守りたいと思います。
こんばんは。わたしは今日、SEとして、つまり障害を報告するプロという立場で増田に来ました。
もちろん、SEだけが障害を出すわけではありません。よく知られているようにPGもバグを出します。ディスク障害、ネットワークダウンのように、ハード屋やら電話屋もそれぞれがそれぞれの障害を出します。しかし、SEのバグは他の人たちのバグとは違います。SEがバグを出して道徳的と称賛されることはありません。それどころか、その障害が大きければ大きいほど、ひどい障害であればいっそう、顧客や上司からの批判が大きくなります。なぜ、そうなのでしょうか?
それに対する私の答えはこうです。すなわち、致命的なタイミングで障害を出す、いってみれば、悪夢を現実にすることによって、SEはシステム投資の重要さを説き、新たな光でそれを照らすことができるのです。多くの場合、開発工程のほとんどを内製化し、正確にシステム化することは事実上不可能です。だからこそ、私たちはPGを隠れた零細企業からおびき寄せ、開発拠点へと運び、一見正社員の形に置き換えるのです。しかしながら、これで障害を起こした場合には、私たちのメンバーの誰が腹を切るのかを明確にしなければなりません。メインフレーム時代に現役バリバリだった時代遅れなPMを安全ピン代わりに上司の席に着かせることは、自分を身を守るのに必要な準備のひとつなのです。
そうは言いながらも、今日も障害を報告するつもりはありません。できる限り先延ばしにします。私が人力で運用フォローをしなくて済み、この時間に帰れる日は月に2、3回しかないのですが、今日はちょうどその日に当たったようです。
真実をお話しします。本社で、かなりの上の人たちから、障害を悟られぬようように、と言われました。ばれたら、私のマイナス査定(降格)を下すと警告する人さえいました。これはもちろん、メインフレーム周りでの激しい障害のためでした。基盤担当の報告では、バックアップの上書きで1000ファイル以上が消失し、その大部分は唯一無二の情報、つまり受注先マスタや売掛金データであったとのことです。
障害の知らせを受けた後、私は何度も自問自答しました。仲間がサーバルームでコマンドを叩き続けているときに自分だけオフィスへ来て、上司への報告書を書くことが果たして正しい行為なのか、今まで機器構成を説明する図が無くて今日初めて作られたことが悟られないか、一部のモジュールのソースと設計書が紛失しており機能を想像して丸ごと書き直さないとバグがつぶせないことをどう説明するか、と。私はもちろん、このような印象を与えたくありません。私はバイナリからの逆コンパイルには反対ですし、ヤマ勘でのプログラミングも支持しません。もちろん、先人の書いた設計書は見つかるはずもありません。
しかしながら、慎重に考慮した結果、最終的に障害を報告しませんでした。この判断の理由の一つは、実に上の立場の人が障害を報告しないようにと私にアドバイスをしたことです。おそらく、他の多くの技術者と同じように、私は上司に言われた通りのことをする傾向があるのです。「言うな」「考えるぞ」「で?」「黙ってりゃわからん」「マイクロソフトのせいにできんのか?」「お前は一言もしゃべるな」と言われると、特に役員の個室に呼び出され「警告」を受けると、それに従いたくなるし、考えたくなくなるのです。これはサラリーマンとして当然の「気質」かもしれません。技術者は普通のサラリーマンなのです。私たちは上司自身の口から出たことや、FW:が5個ほど連なったメールにしかすんなりとは従えないのです。
というわけで、私はここにやって参りました。遠く離れているより、増田に来ることを選びました。コンソールを見つめることより、PCを見つめることを選びました。皆さんに何も話さないより、話すことを選んだのです。ここで、非常に個人的なメッセージをお話しすることをお許しください。それはコードを書いているときにいつも心に留めていることなのです。紙に書いて壁に貼ろうとまで思ったことはないのですが、私の心の壁に刻まれているものなのです。それはこういうことです。
「高くて、固い壁があり、それにぶつかって壊れる卵があるとしたら、私は常に壁の側に立つ」ということです。
そうなんです。その壁がいくら正しくなく、卵が正しいとしても、私は壁サイドに立ちます。他の誰かが、何が正しく、正しくないかを決めることになるでしょう。おそらく労基署や裁判所というものが。しかし、もしどのような理由であれ、顧客の立場に立って正直に報告書を書く技術者がいたら、上司はその部下にいかなる価値を見い出せるのでしょうか?
この暗喩が何を意味するのでしょうか?いくつかの場合、それはあまりに単純で明白です。納期前倒し、瑕疵責任、仕様変更、出精値引、SLA無視は高い壁です。これらによって押しつぶされ、徹夜し、心理療法を受ける非正規の下請けたちが卵です。これがこの暗喩の一つの解釈です。
しかし、それだけではありません。もっと深い意味があります。こう考えてください。私たちは皆、多かれ少なかれ、卵なのです。私たちはそれぞれ、壊れやすい殻の中に入った個性的でかけがえのない心を持っているのです。わたしもそうですし、皆さんもそうなのです。そして、私たちは皆、程度の差こそあれ、高く、堅固な壁に直面しています。その壁の名前は「システム」です。「システム」は私たちを守る存在と思われていますが、時に自己増殖し、私たちを殺し、さらに私たちに他者を冷酷かつ効果的、組織的に殺させ始めるのです。
私が報告書を書く目的はただ一つです。個々の下請けが業務を担当したエビデンスを集め、それに責任を与えることです。報告書を書く目的は、「システム」の網の目に自分の魂がからめ捕られ、傷つけられることを防ぐために、「外注先」に対する警戒警報を鳴らし、注意を向けさせることです。私は、設計書への検印、テストの実施担当者の検印、ソースの最終更新者、リリース時の立会い責任者、打ち合わせ記録書の参加者などのエビデンスから個人を槍玉に挙げた報告書を書くことで、自分を守り、壁を守り、下請けを破壊することがSEの仕事であると心から信じています。というわけで、私たちは日々、本当に真剣にエビデンスを積み上げていくのです。
私の先輩は昨年、40代で亡くなりました。先輩はPGで、時折、SEをしていました。金融のSE だったとき、徴PGされ、中国のオフショアに送られました。先輩の隣のチームだった私は、先輩が昼食後に毎日、たくさんのお薬を飲んでいるのを見るのが日常でした。ある時、私は先輩になぜそうまでして働くのかを尋ねました。先輩の答えは、これまでデスマで散った人たちのために戦っているとのことでした。先輩は、顧客であろうが上司であろうが関係なく、残ったメンバーのために開発を続けているとのことでした。先輩が会議室でのレビュー中に焦点の合わない目を見開いたまま俯いている顔を見たとき、先輩の周りに死の影を感じたような気がしました。
先輩は亡くなりました。先輩は残りのメンバーが決して知り得ない仕様も一緒に持っていってしまいました。しかし、メインフレームの周辺に潜んでいたJCLの仕様の一部が既に転職していったメンバーの記憶に残っており、相手の迷惑を顧みずにばんばん電話で聞いています。以上のことはプロジェクト管理のことでわずかにお話しできることですが、最も重要なことの一つです。
今日、皆さんにお話ししたいことは一つだけです。私たちは、国籍、人種を超越した人間であり、個々の存在なのです。「システム」と言われる堅固な壁に直面している壊れやすい卵なのです。どこからみても、勝ち目は見えてきません。壁はあまりに高く、強固で、冷たい存在です。もし、私たちに勝利への希望がみえることがあるとしたら、私たち自身や他者の独自性やかけがえのなさを、さらに魂を互いに交わらせることで得ることのできる温かみを強く信じることから生じるものでなければならないでしょう。
このことを考えてみてください。私たちは皆、実際の、生きた精神を持っているのです。「システム」はそういったものではありません。「システム」がわれわれを食い物にすることを許してはいけません。「システム」に自己増殖を許してはなりません。「システム」が私たちをつくったのではなく、私たちが「システム」をつくったのです。
これが、私がお話ししたいすべてです。
「自宅謹慎1ヶ月」、本当にありがとうございました。一旦は闇に葬られた私の報告書が形を変えて増田の多くの人々に読まれていることはとてもうれしいことです。増田の読者の方々にお礼申し上げます。私がここに来たもっとも大きな理由は皆さんの存在です。私たちが何か意義のあることを共有できたらと願っています。今日、ここでお話しする機会を与えてくださったことに感謝します。ありがとうございました。
えっと、これ、ネタですか?
SLAは文字の通りAgreementなんで、契約ですよ?非常に高い?それは具体的に何ですか?
内容の無い契約なんか出来るわけ無いじゃないですか、Availabilityがですか?年間何分のダウンまで許容できますか?
そこら辺をきちっと説明してもらわないと見積もりなんてやりようありません
機械は壊れるものですし、プログラムはバグがあるものです、もちろん、そういうのが全く許容できない用途だって言うのなら
そう言ってくれれば済む話ですし、そういう場合は、一年分程度の全入力を機器に流してみたりもします
具体的に、このシステムの停止時間で許容できるのは年間何分の停止である、ついては見積もりだしなさいと言えば済む話でして
それはやりたくない、という話なら、今のままの契約と機器しか無いと思います
しかし、それって言ってしまえば、ダウンは全く許容できない、遅延も許容できない、って言ってるのと同じ事で
ベンダに対してそれを言うと
例えば、壊れない車をよこせって言ってるのと同じ事で、そう言われてしまうと、専門のエンジニアを常時待機させた上で
代替車を全国に10台常に確保し、ヘリで故障地点まで運ぶ体制を作りますみたいな案が出てきて当然なんです
もちろんそういう用途はありますし、そういう体制が必要かどうかはユーザーが判断することです
こっちは、言ってしまえば、地震がおきても通話に制限が無い携帯電話網を作れと言ってるようなもんで
どの程度の負荷を想定して、想定した負荷の場合の応答時間は何秒だ、それを守れって言われないと
際限なく金をかける結果になります
まぁ、言っちゃえば、世界のどこで何があるか分からないから
日本人の脱出用の航空機を世界の全空港に手配する必要があると思います?
そんな話なんですよ