タグ

エンジニアに関するitboyのブックマーク (8)

  • メンテナンスやトラブルの際にディレクターがしておいた方がいい“8”のTips : LINE Corporation ディレクターブログ

    ディレクターの渡邉雄介です。担当しているサービスのメンテナンスやトラブルがあったとき、初動が遅れたり、パニックになって判断能力が鈍ってしまったことはないでしょうか? ディレクターブログでは、すでに何度か障害時の基的な対応についての記事 (障害対応的ディレクションスキル・サーバ障害と向き合うには) が書かれていますが、今回はもう一歩踏み込んで、メンテナンスやトラブルの際にディレクターがしておいた方がいいTipsをいくつかご紹介します。 Tips1. トラブルの第一報だけは最速で開発メンバーに伝える 責任感の強い人は、まずはディレクターが問題をある程度取りまとめてからエンジニアや関係者に共有……と思いがちですが、たとえその時点で問題をよく把握できていなくても、障害が起きているということだけは最速で伝えるべきです。これは下記の2つの点から重要です。 ◆ひとりよりも複数で問題に取り組んだ方が解決

    メンテナンスやトラブルの際にディレクターがしておいた方がいい“8”のTips : LINE Corporation ディレクターブログ
    itboy
    itboy 2011/07/14
    抜本的な解決策を実行する前に回避策が無いかを模索するのも大事かな。
  • オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい

    最近は、@kazeburo さんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは 1 年前くらいで、その時僕は 2 年目に入ったところで MySQL Conference から帰ったばかりで「おらは DataBase Administrator(DBA)なんだ!」と思ってた頃でした。 それからちょうど 1 年。1 年目の時も DB だけをやってたわけではないですが、この 1 年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど ん、ちょっと待てって?

    オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい
    itboy
    itboy 2011/05/17
    あとで読む
  • 35歳を超えたエンジニアの5つの働き方

    おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 ぼくは36歳です。けっこう大きなサイトで、RailsJavascriptを書いたり、パフォーマンス改善したり、iPhoneアプリの開発でObjective-Cを書いたりしています。マネージメントはしていなくて、今でも普通にエンジニアとして働いています。 35歳定年説の35歳を超えてから1年以上が過ぎたところですが、昔のようにはいかなくなってきたところ、昔と変わらないところ、昔よりよくなってきたところなどがいろいろあります。年を取ってもエンジニアを続けたい人の参考になるかどうかわかりませんが、そういう人たちのためにぼく個人の体験をここに書いておこうと思います。 1.理解できるまで聞き返す 特に若い人たちとの会話で痛感するのですが、相手の言いたいことを一度で理解することが難しくなってきまし

  • エンジニアとしての歩き方 - 都元ダイスケ IT-PRESS

    これから書くことは決して「これをしなければいけない」とか「他に手段はない」なんてコトを主張したいのではない。色んな道があるはずだぁ。その中の一つの事例として、自分がやってきたことをフレームワーク化し、色々挙げてみようと思う。 当然、俺の主観が入りまくっているので、突っ込みどころは満載だろうなw そもそも「エンジニア」って何?w その辺り、はてブ界隈のミナサマにおかれましてはお手柔らかに願いたいww さて、いきなりどこかの技術系カンファレンスで1時間喋っちゃえ、とか突然は無理なのは分かる。何を話せばいいのやら、どこに喋るチャンスがあるのやらだ。しかし、そういう所で喋るような自分を将来のビジョンとして持っている人は、以下に挙げることを小さなことからコツコツと実践してみるといいかもしれない。という意図で書いていく。 何事にも興味を持とう 興味は勉強の原動力。興味のない勉強は苦痛でしかない。ここが

    エンジニアとしての歩き方 - 都元ダイスケ IT-PRESS
    itboy
    itboy 2009/07/08
    エンジニアとしていざるをえない環境を作ってしまうってことかな。
  • 10倍できて志あるエンジニアがとるべき戦略 - 最速配信研究会(@yamaz)

    仙石さんが志が高く優秀だけど,あんまり金銭的に恵まれない技術者のことを憂慮されている. 「技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき」 http://sengoku.blog.klab.org/archives/64945422.html 志のある仕事(OSSの普及やボランティア活動など)は率直に言うとあんまり金銭的には儲からないことが多い.だからそこをメインの糧としてがんばり自分をすり減らすよりも,もっと効率いい方法で儲けておいて,余った余力で真にやりたいことをやった方が自分のためにも社会のためにもいいことだと思う. ただ仙石さんの言うように「だからビジネスモデルに敏感になれ!」というはまぁそうなんだけど,率直なところ「簡単に言うなよ」とも思う. だから私がもし当に10倍パフォーマンスがあって志あって,真に自分のやりたいことのあるエンジニアだったら,会社には2倍

    10倍できて志あるエンジニアがとるべき戦略 - 最速配信研究会(@yamaz)
    itboy
    itboy 2009/01/19
    個人のやりたいことでも、どれだけ個人だけのことじゃないのかが重要なのかもしれないと思った。
  • 「素晴しいアイディア」が採用されない理由:Geekなぺーじ

    エンジニアによる技術革新を妨害するのはエンジニア」という記事はあまりに視点が一方的です。 「アイディアは全てが正しい」と主張する馬鹿が書いた文章としか思えません。 ここでは、アイディアを否定する立場側で考えてみました。 以下、あっさりとアイディアを否定される場合にあり得そうなことです。 技術的な面を全く考慮していない。 技術的に不可能な事を要求していませんか? 運用に関して全く考慮していない。 作ったら終わりではありません。 作り終わってからが番です。 財務面を全く考慮していない。 収支度外視で考えていませんか? 詳細を詰めていない。 全てが大雑把ということはありませんか? 人的資源を考慮していない。 実行するメンバーに関して何も考えていないということはありませんか? 説明が足りていない。 十分な説明をしない状態で相手に「ご理解」を求めていませんか? 情熱が足りない。 思いつきで言って

  • フリーSEとして働いていますが,最近立て続けに契約を切られ,将来が不安です。

    Q: 個人事業主でSEをしていますが,契約を切られることが増え自信をなくしています。個人事業主で続けていくには限界があるのでしょうか? スキルアップのため,個人事業主でSEをしていますが,ここ数年,二重派遣などの契約問題で,現場を切られることが増えました。 現場にアサインされたら,チームリーダーや時にはプロジェクト・マネジャーの補佐役として管理系の仕事を任されるので,スキルが原因ではないことは明らかですが,こう立て続けに契約を切られると自信をなくしてしまいます。 また,収入面での安定性も得られないため,社員や契約社員への転向も考えています。個人事業主で続けていくには限界があるのでしょうか?何か良い対策方法があれば,アドバイスをお願いします。 (SE/男性・37歳) A: 自分への自信を失うな。営業が不安なら,営業力のある仲間を集めよ 今回の金融恐慌が始まる以前から,IT業界では金融業界を中

    フリーSEとして働いていますが,最近立て続けに契約を切られ,将来が不安です。
  • Geekなぺーじ : エンジニアが見落としがちなこと

    過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く

  • 1