読者です 読者をやめる 読者になる 読者になる

冒険の書

27歳と6ヶ月のときに未経験でITエンジニアに転職した元派遣会社営業職(文系)が綴るブログです。同じように20代後半から未経験でIT技術者に転職することを検討されている人に「27歳からの未経験がどれだけ成長できるか」という点などで参考になれば幸いです。

Lenovo T440p Ubuntu 14.04 をアンインストールし Windows 8.1 を再インストールする方法

Lenovo T440p にインストールした Ubuntu 14.04 が不要になった。元々インストールされていた Windows 8.1 を再インストールすることにした。当初、懸念していた Ubuntu のディスクからの消去は Windows の機能でディスクを完全消去することで無事解消できたが、別件で悩まされたので備忘録として記録する。なお、筆者も詳しくはなく、かなり適当な設定変更であるため、そのあたりも留意されたい。

 ディスクを完全消去後に再インストールが実行不可

 ディスク完全消去後に再度、言語、キーボードを選択するが、途中で80004001のエラーが発生して立ち行かなくなる。考えられる原因は、ディスク完全消去後に表示された「Comfirmation」という内容。

表示された内容は、TPM(セキュリティチップ)に関したものだ。調べたところ、BIOSから変更可能だという。

BIOSTPMに関する設定を変更する

Lenovo T440p では、F1 で BIOS 設定画面へ遷移する。

  • セキュリティ関係の動作をすべて Disabled にする。
  • それだけでダメであれば、Restart タブに存在する デフォルト設定に関する設定を無効にする。

以上

 

なお、Lenovo T440p には、Windows 8.1 のリカバリディスクが存在しない。そのため、USBに同機能を作成する必要がある。リカバリディスク自体の作成方法は、他のWEBサイトを参照されたい。

 

また、今回、筆者が使用した機器は以下である。

 

研修が終わって2ヶ月を振り返る

2015年10月から研修を行った4人のうち3人は昨年で研修を終え、今年からは現場で働くことになった。

自分の場合は、研修先に気に入ってもらえてそのまま継続となった。

その後、2ヶ月が経過し、3月を迎えようとしている。

ふと、他の現場で全く違う業務に従事しているはずであるもと研修仲間は自分に比べて遥かに成長しているのでは?という焦りを感じた。

そこで、今後の成長の指針にすべく、今年の1月から2月を振り返ることにする。

 

1月

  • 年始は、昨年末から持ち越しとなった性能調査の最終確認を行った。
  • MySQL Fabricの調査を行った。
  • MySQL 5.7 のinnodbページ圧縮の調査を行った。
  • 初のクエリチューニングを行った。
1月の成長

クエリチューニングを経験出来たのがかなり大きかった。いきなり、クエリの8割を書き換えなければいけないようなくそクエリを任せていただけたおかげでクエリチューニングの能力はかなり向上した。1月の成長としては、これが大きかった。

MySQL Fabricの調査に携われたのもよかった。NoSQLでシャーディングが注目されているなか、MySQL Fabricはそれを実現できるため注目されているソフトウェアであり、今後必要とされる知識である可能性が高いからだ。そして、シャーディングという概念を明確に理解する良いきっかけとなった。

2月

  • MySQL 5.7 検証資料作成
  • 一般クエリログ調査
  • グループごとに連番を採番するSQLの作成
  • 高可用性ソリューション資料の作成
2月の成長

2月は1月とは異なり、DBとは離れたところで勉強になるところが多かった。

一般クエリログではログを整形する力量の無さを痛感し、SQL作成では、SQLについての知識不足な所為で、わかっている人であれば10分で出来てしまうようなことも3時間もかけてしまっていた。

また、高可用性ソリューションではPacemaker,DRDBなどに触れることができた。

 

こうやって振り返ると、2月は失敗ばかりでほとんど成長できていないことがわかる。

このままではいけないので3月度の目標を、現在わかっている案件も含めて考えみようと思う。

  • javaを覚えてMySQL Fabric対応のtpcc-mysqlを模したソフトウェアを作る。
  • 基本情報技術者の勉強を大方終わらせ、2周目に入るようにする。
  • 高可用性ソリューション等、MySQLと組み合わせられるソフトウェアのをひと通り構築する。
  • MySQLの基本的なことを突き詰める。

 

営業から技術者に転職して、3年目に気付いた「転職して良かったこと」。

 2011年9月から2年ほど派遣会社で営業職を経験し、2013年12月からIT技術職へ転職しインフラエンジニアとして歩み始めて早2年。昨年は技術者に転職してからの初めての転職を経験し、2015年10月から2社目の会社でDBAとして、日々励んでいる。

 そんな年明けのある日―2016年1月下旬―、大きな案件の受注に必要なプレゼンを任せられたが、準備が足らず、自分の力不足で見送りになってしまい、自己嫌悪に陥っていた頃、ふと、自分の「得意なこと」に気付いた。

”自分が注力しているわけではないのに褒められた事があったら、それが「得意」なことだ”

 今までそんなことないと思っていたが、急に技術者に転職してからのある部分で共通するワンシーンが複数脳裏に蘇った。

設計書の読み合わせの際に―

○○さんって、一つのことをとても細かく調べるよね。

脆弱性発覚の際に―

技術的な詳細な説明は○○さんにお願いします。

本番システムへの変更申請書を提出した際に―

とても素晴らしい内容で、本来であれば必要な技術レビューなどの審議は不要です。システムへの変更を許可します。

 この他にも、自分が事細かに調べたことで未然に防ぐことができたケースはあるが、ここで重要な気付きはそこではなかった。重要なのは、自分としては当然な知識の深さが周りとは違ったことだった。自分としては、「ここまで必要だろう」と思っていることでも周りはその必要性に気づかず、話してもその必要性の理解には至らなかった。

 これを私は、「自分には、他の人が調べないような詳細な箇所まで調べることができる能力がある」と解釈した。これは、決して無駄になるわけではなく、実際に、自分の懸念が実現し、努力が功を奏したことがあった。 

 今まで、仕事が遅いだの、そんなところまで調べる必要はないだの、私の仕事ぶりは決して評価が良いものではなかった。そして、今後もそれは変わらないだろう。納期がある以上、7,80%の出来でも早く出来たほうが良いのだ。というか、上長などは、品質の詳細まではチェックしないから、早く仕上がれば品質など気にせずに良い評価を下すのだ。

 しかし、私は良い言い方をすれば「責任感がある」、悪い言い方をすれば「完璧主義者」。お金を払ってもらっている以上は、非の打ち所のないものを納品したいのだ。そんなことは、自身の能力からは到底無理と自覚していても、その理想の炎を燃やし続けていたい。

 以上のような経緯で、29歳にして30回目の冬に、ようやく「自分の得意なこと」を見つけることが叶った。

 これが、私が営業から技術者に転職して良かった、と思えたこと。

  「自分の得意なこと」が見つかったことで、自分の中に迷いが消えた。自分の武器が見つかる―自分のアイデンティティが確立される―ということがどれだけ素晴らしいものか。胸を張れるものが自分の中に存在するとはどれだけ気持ちがいいものか。一本の柱が自分の中に出来た感じがしてとても安心した。私はこれからはこの武器に更に磨きをかけることに専念することができる。

 しかし、だからといって仕事が遅くていいというわけではない。何事も適材適所である。早さが求められる場面では可能な限り早くすることをこれからも心がけ、反対に品質が求められる場面ではここぞとばかりに本領を発揮できるようにしたい。冒頭の失敗を二度と繰り返さないように、この武器を人生かけて磨き続けていく所存である。

 

                                2016年2月5日

checksum tableをストアドプロシージャにしてみた。

checksum tableのテーブル名を決め打ちではなく、融通を効かせるようにしたいなーという構想から、information_schemaから該当するスキーマから存在するテーブル名を引用してchecksum tableを実行する、というストアドプロシージャを作成(未完)した。

 

以下、所感。

  • 理想は結果をテーブルに格納して比較しやすいようにすることだったけど、無理ポ。
  • 現在はスキーマ名は決め打ち(tpcc)だけど、そのうち引数でスキーマ名を可変にするつもり。
  • 動的なSQL文の作り方を覚えられてよかった。
  • Thread stack overrun:が出力された場合は、thread_stackを増やそう。
  • 初めてのストアドプロシージャ作成にしては、まぁいいんじゃないかな(笑)
create procedure chksum()
 BEGIN
    DECLARE tbl_name char (10);
    DECLARE tblCur cursor for SELECT table_name FROM information_schema.tables WHERE table_schema = 'tpcc';

    SET @pos = 0;
    SELECT COUNT(*) INTO @total FROM information_schema.tables WHERE table_schema = 'tpcc';

    open tblCur;

    WHILE @total > @pos DO
      FETCH tblCur INTO tbl_name;

      SET @str = CONCAT('checksum table tpcc','.',tbl_name);
      PREPARE stmt FROM @str;
      EXECUTE stmt;

      SET @pos = @pos + 1;
    END WHILE;
    CLOSE tblCur;
  END

参考

SQL 基本のき CONCAT・EXECUTEで動的なSQL文の実行 MYSQL編

 

2015年を振り返る

2015年も、本当にいろいろありました。

2015年以前も、いろいろありましたが、今年は本当に成長を感じられる年でした。

2013年11月末日に、2年強務めた派遣会社の営業職を離職し、27歳にして、未経験で派遣社員としてエンジニアへ転職しました。

2015年9月末日、初めての現場で任されたPJを当初のスケジュール通り完遂することができました。

そして、2015年10月より、新たな会社へ転職し、3ヶ月間の研修へ入りました。

その研修がとうとう今月で終わりました。

 

その過程で、本当に多くのことを感じ、自分の成長を感じるところもあれば、三つ子の魂百までとばかりに、まったく成長を感じられないこともありました。

以下では、そんな今年を今後の自分にために振り返っていきたいと思います。

 

1月

新サービスで使用するリバースプロキシの構築も完了し、小休憩となった1月。ドキュメント作成メインの定時上がりの毎日だった……が、しかし。

恵方巻きももう目と鼻の先まで近づいていたところで耳に入ってきたのは、glibc脆弱性「GHOST」でした。自分自身は、この脆弱性によるサービスへの影響はないと判断していたため、対応に消極的でしたが全体判断で対応を迫られることに……。

プライベートでは、猫カフェにハマっていろいろな行っていた。

2月

脆弱性対応の対象となるのは本番9台開発9台の計18台。それらは私が着任してからは一度もOSの再起動をしたことがなく、我々もヤブを突くような真似は極力避けてきたため、OS再起動を実施するのはこれが初めてだった(研修中に1回だけ開発の1台を再起動した実績はある)。

苦労したことは主に2点。再起動手順の作成と、正常性を担保するためのテストケース。

前任がいた時はベテランエンジニアもチームに含まれていたため、再起動手順は手順書としては存在しなかった。そのため、2014年夏に私が作成したものしかなかった。それは当時のリーダーに承認を得ていたものだったが、私としてはどうも納得がいかなかった。そして、その手順書が実際に必要となった今回の対応で再び見たところ誤解を招きかねない書き方であったため局所的に見直しを図った。個人的な価値観だが、手順書というものは、月曜日の朝や夜間の救急対応時などに、頭を空っぽにした状態でも、書かれた手順を上から下へ読み飛ばさず実施すれば、目的を完遂できる水準になければいけないと思っている。以前私が作成した手順書は到底、そのレベルには至っていなかった。

この手順作成は、サービスの起動や各サービスの役割や仕組みを再認識するのにとても役に立ったと思っている。この手順の見直しを通して、私は自分の管理対象であったサービスにより詳しくなることができた。

 

テストケースについては、相方が作成を主に担当した。相方だけに正常性を担保するための業務を押し付けるわけにもいかずサポートしたが、正直あまり力にはなれていなか

った。サービスの正常稼働を担保できるテストケースは作成できた(と思っているが)が、実際にどこまでやれば担保できるかというのがあのときの自分では判断がつかなかった。おそらく、今(2015年末)の自分であれば、もう少しマシな判断ができていることだろう。とにもかくにも、テストというのは難しい。

そんなこんなで、2月はこのテスト1ヶ月をまるまると費やしたのだが、実は水面下で別の問題も姿をちらつかせていた……。

プライベートでは、OpenStackの導入に挑戦していた。いろいろ試した結果。ConoHa上でのRDOしか成功しなかった。

3月

2014年末の打ち合わせ時から、その顧客が2015年3月〜4月にサービスを開始したい旨は周知されていた。当然、主担当であり、プロジェクトの舵取りをしている自分もそのスケジュールで動いていたのだが2月中旬に思わぬ事態を迎える。

―リリース判定が進んでいない

リリース判定は、派遣社員ではできない。派遣先の役職者が行うものだ。それが、その上司が多忙であったこともあり、手が付けられていなかった。

システムをリリースするにあたり、そのシステムがリリースするに妥当なものかを複数の会議体で決議を採る必要がある。これは、通常なら1ヶ月を要するとのことだった。しかし、事態はそんな悠長なことも言っていられなかった。この話が噴出したのは2月中旬。顧客は早ければ3月には新サービスをスタートしたいと言っている。そのため、急ぎで各所に対応を依頼したが、今度は、旧サービスと新サービスで利用形態が違うことやそれに伴うシステムへの設定の変更の必要やら、様々な問題が噴出してきた。

これまで契約側や企画側とコミュニケーションを取っていたことが功を奏したのか、顧客とも調整することができ、なんとか4月からの新サービスのスタートへは漕ぎつくことができたが、新サービスへの移行でもDNS切り替え後の対応を誤ってしまったりと3月も1ヶ月を通して大変なひと月だった。

ちなみに、DNS切り替えの件だが、通常DNS切り替えは事前にTTLを短くしておけば(たとえば5分とかに)切り替え後5分経過すればキャッシュが消失し、新たにDNSへ問い合わせを行い新たなDNSレコードを参照するが、社内プロキシを利用していたいるすと、うまくいかないことがある。

プライベートでは、たしか Linux from scratch にこのあたりで挑戦していたはず。

そして、初めてロードバイクに乗った。

4月

新サービスも無事サービスインとなり、一息つくことができたが、社内体制の変更により引き継ぎ関係で慌ただしくなった。それ以外を除いては、システム的にも落ち着いたひと月だった。

5月

新サービス用の開発サーバでメモリの異常な上昇が継続して観測された問題を解決することができた。原因は、curlのバグ。環境変数を適用することでメモリ使用率を下げることがわかった。

6月

この頃から徐々に転職を意識し始めるようになった。それは、現在の自分の置かれている立場が派遣社員であり、PJの収束とともに契約満了を言い渡される懸念があったからだ。

この頃に行った担当営業との面談では、Linux案件はない、と言われた。NW系を拡大していきたいと。自分としては、未経験から約2年間に渡り積み上げ続けてきたLinuxに関するスキルを伸ばしていきたかったし、その方が収入に繋がると思っていた。

次の話が出てこない上にNW系しかないのであれば、早々に自分から転職先を見つけておきたかった。

7月

顧客より、障害確認の連絡があった。APサーバからのレスポンスでエラーが頻発し、エンドユーザのビジネスに影響が出ていると。しかし、我々のシステム上には被疑はなかった。結局のところ、NW側の問題であった。ルータがNAPTする際に送信元ポートを割り当てるが、その動作がインクリメント方式からランダム方式に変わってしまったこと及び、その割り当て間隔(time_wait)が0秒(Linuxなら60秒)であったため、time_wait前に送信元ポートを再利用してしまい、信元ポートが重複することにより受信側でRST ACKを返してしまいエラーが発生していたことが判明した。

その他には、恒例のBIND脆弱性対応。

プライベートでは、転職に向かって少しずつではあるが動き出した。

8月

転職活動というものは難しいもので、案件だけではなく、待遇面や会社の規模、ネームバリューなどいろいろな要素を考慮しなければならない。その中でも、待遇については最終面接に合格し、待遇条件を提示されるまでは気が抜けない。安易にどんな条件でも御社になどと言ってはいけない。さもなくば、自分の想定していた条件とはかけ離れた待遇を提示され落胆の色を隠せないことだろう。自分自身、賞与や残業抜きでは、現職よりも下がってしまうことになり、待遇面では納得がいく転職ではなかった。

無事転職先が決まった8月中旬、現職の会社に退職届を提出した。もちろん、引き止めくださったが、丁重にお断り。その後も、職場まで面会に来られての引き止め面談が行われたが改めて丁重にお断り。

9月

作業がある日のみ出社し、残りはすべて有給消化に充てた。たしか、10日も出社しなかったはず。休んでいる期間はDBの勉強をしたのだが、正規化などの勉強ばかりで、全然MySQL自体の勉強をしなかったせいで、次の会社へ入社してから大変だった。

10月

入社時研修を終えた直後から研修先でのMySQLの研修が始まった。

最初は座学をしつつ、練習でのレプリケーション構築作業を行った。

11月

Galera Cluster を MySQLMariaDB で検証する作業が始まった。この作業では、検証環境の構築からも行い、yum のローカルリポジトリやHAproxyについて学ぶことができた。また、ssh接続する際に sshpass というコマンドで ssh 接続時のパスワードを入力不要する方法を学べたことも大きかった。更にリーダー的役割を担わせていただけたことで、リーダーとしての働き方に自信がついた。

後半からは検証の自動化のためのスクリプト作成も任せていただけて、今までbashでまともにスクリプトを書いたことがなかったのでこれも大きな勉強になった。

しかし、スケジュールが押していることを理由に、歓迎会を断ってしまったのがイタイ。

12月

MySQL についての性能調査を任せていただけた。これにより MySQL について全体的に詳しくなることができた。また、MySQL に関する2つの資格(DBA,Developer)を取得することができた。

プライベートでは、サバゲーを初体験できた。

 

以上、簡単ですが、2015年の振り返りとなります。

以下、2015年の総括です。

技術的な観点では、LFSをしたりカーネルに手を出したりと多少は技術の深堀の第一歩を踏み出せた感じでした。

仕事的な観点では、やはりイージーミスがつきまといます。また、時間をかけすぎてしまう傾向があります。

その他では、ロードバイクやサバゲー猫カフェ、水泳に挑戦することができました。水泳に至っては生まれて初めて25mを泳ぎ切るという快挙(笑)を成し遂げました。また、転職してからは少し体を絞ることができました。(またリバウンド気味ですが……orz

女性関係は、一切進展なしです。

しかし、仕事を通じて自分の成長を感じられたことが大きいです。

 

さて、2016年はというと。

技術的な観点では、MySQL を柱として知識を広げていくつもりです。また、春に基本情報技術者、秋に応用情報技術者に合格する予定です。

仕事的な観点では、イージーミスを減らし、より短時間で、より高品質の成果を出せるよう考え方を再構築していきます。

その他プライベートでは、今年はダーツに挑戦してみたいと思います。また、1人ボウリングなんかもしてみたいですね。あと、ボルダリングへもコンスタントに通いたいです。

恋愛は、誰かいい人が見つかればいいなーってかんじですかね。

そして、人間としての成長をやはり一番に考えていきたいですね!他者への、感謝や尊敬、尊重を忘れずに、自分の学んだことをフィードバックしていきたいです。

 

2016年は30歳という節目です。

今まで以上に飛躍となる一年にしたいと思います。

 

MySQLの研修開始から経過した2週間を振り返って。

1週目

課題と成果

課題

基本、テキストを配られてそれを教材に学習する自習方式だが、チームに分かれてのMySQLのマスター/スレーブのレプリケーション構築(GTIDあり)およびその手順書作成の課題は頂いた。それとは別に、とにかくMySQLを少しでも知る、というアバウトな課題を自分で設けた。

結果

上記レプリケーション構築およびその手順書作成は無事完了した。その他、自習の成果として以下がある。

1週目の反省

レプリケーションで多くのサーバを立てることから作業サーバをわかりやすくしたいと思い、/etc/motdにAAを描いていて、それに数時間費やしたこと。

2週目

課題と成果

課題

  • テキストでの自習
  • ローカルリポジトリの作成
    Galera用パッケージをrpmで個別インストールする際に発生する依存関係を解決するため、というのが目的
  • 検証環境へのパッケージインストール
  • Galera Cluster for MySQLを用いたMySQLのマスター/スレーブのレプリケーション構築

結果

  • テキストでの自習は捗らなかった。内容が頭に入ってこない。
  • ローカルリポジトリの件については、以下が勉強になった。
    • yumのlocalinstallサブコマンドでローカルのrpmをインストールする際に依存関係を別のリポジトリで解決できることを覚えた。
    • マウントなんてLPICの勉強以外でほとんど経験なかったんだけど、isoファイルをマウントする必要があり、良い復習になった。
  • 検証環境へのパッケージインストールは特に大きな苦労はなかったが、いくつかメモ。
    • 他のメンバー(経験浅い)も理解および実施可能な手順書を作成する必要があったが、下手に親切設計にすると更に誤解を招くため"簡便さ"の難しさを痛感した。
    • 講師との意思疎通が足りなかったため。講師の想定通りとはならなかった。どうにも、あの講師は説明不足だ。せっかちなんだろう。あの人と仕事をするときは、要件を聞き出さないと失敗するだろうから気をつけなければいけない。
    • Linux コマンドを少し学んで欲しいということでscp使ってを各検証サーバから取得するような手順にしてほしいとのことだったが、なにをどういうふうに取得させるかなど、気を使った。結局、取得先に用意したrepoファイルとrpmファイルをtar.gz形式にまとめたものを取得してもらい、取得後に展開してもらうだけの手順とした。
  • Galera用MySQLを用いたマスター/スレーブのレプリケーション構成については以下の縛りを設けて行った。
    • 1週目に作成した構築手順書は見ない
    • ブログなどの答えが書いてあるページは見ない
    • MySQLの公式マニュアルしか見ない

      その結果、GTIDなしは簡単だったが、GTIDモードありはちっともCTIDがONにならず手こずった。しかし、マニュアルの見方や、最低限の必要な設定がわかったりと実りも多かった。

2週目の反省

innodbの仕組みを学ぶはずが、座学が全く頭に入らず、無為に時間を過ごしてしまった。
もっと、効率化を意識しなければいけない。

総括

Galeraを初期設定できるくらいで、大して技術力は身についていない、というのが現実。簡単なことしかしていない。
とにかく、もっとMySQLを学ばなければいけない。

以上

2015年10月11日(日)、2015年10月12日(月)※祝日

私信

3連休の結果をその最終日に書くはずが、時がすぎるのは早く、あっという間に週末。

最近、時間が過ぎるのがとても早く感じる。「こうやって、気づく間もなく年をとっていくんだろうなぁ」と。

だからこそ、日々、自分の肉体が確実に寿命に向かっていっている、ということを意識して生きていかなければならない、と思っている。

  

閑話休題

■2日目の取り組み(成果あり)

  • Galera Cluster 3台での”正常な”動作確認。
    →  1日目は、"正常"の判断基準が誤っていた。
  • kvmゲストOSからyumが失敗した現象について。
    → reiserfsprogs が原因だったかもしれないが詳細は不明だが現象からは復旧。"詳細不明"というのは、対応として、kimch導入時にインストールしたパッケージを一つずつアンインストールすることにしたが、依存関係で必ずしも"一つずつ"というわけにはいかず、このreiserfsprogsも例に漏れず……。
  • MariaDBに外部から接続できない件について。
    → mysql_secure_installationを実行したら、リモートログイン可能になった。もっと勉強する必要がある。
  • tpcc-mysqlで同ホスト複数ユーザから同時にテスト可能なことを確認。
    → Dead Lock 多発。アクセス対象は1台に絞ったほうが無難か……。

■2日目の出来事(成果なし)

2日目は、すべて成果が出たので、記載事項なし。

▲2日目の反省

yum問題に半日かけてしまったこと。端からパッケージを一気にアンインストールしていればよかった。手段が目的になってしまっていたorz

■3日目の取り組み(成果あり)

http://galeracluster.comのドキュメント読み込み。
→ Galera Cluster for MySQLを動作させる基礎が身についた。

■3日目の取り組み(成果なし)

取り組み自体が少なかったこともあり、記載事項なし。

▲3日目の反省

動画閲覧や他のことにのんびり時間を使いすぎた。用事で外出は仕方ないにしても、午前中および帰宅後であまりにも進まなすぎ。3日目はVMすら起動していない気がする。反省。まだまだ、ハングリー精神が足りない。

◆3連休終わっての、今後課題

  • やはり、何にもまして、集中力やハングリー精神を保つこと、常に意識することが大切。
  • ドキュメントの読み込みよりも、併せて手を動かすことを意識すること。