AWS案件が2ヶ月経過したので仕事内容を解説【2ヶ月連続お給料が過去最高額】

URLをコピーする
URLをコピーしました!

こんにちはインフラエンジニアのしょうです!(元プログラマー )

この記事では

  1. インフラエンジニアの仕事内容(経験7ヶ月目)
  2. インフラエンジニアのお給料(経験7ヶ月目)
  3. インフラエンジニアとして働いた感想(経験7ヶ月目)

上記の3点について解説していきます!

この記事では2021年5月の働いた内容で、給料も5月支給の内容です。(派遣で勤務しています)

4月の労働が5月に振り込まれる。

4月からAWSを利用している現場で働き2ヶ月が経過したので、未経験の方でもできるだけ分かりやすく実際の仕事内容についても解説していきます。

僕は初めそうだったのですが、インフラの仕事ってどういうものかイメージしづらいんですよね。

インフラの仕事やエンジニアのリアルな収入に興味のある方は結構参考になると思います。

過去のエンジニア勤務の記録は下からご覧いただけます。

記事の内容

インフラエンジニアの給料(経験7ヶ月目)

今月から4月に参加した新しい案件の初めてのお給料が入りました。

4月からは時給制ではなく月給制で最低でも35万円いただけます。

雇用形態は派遣ですが、会社員と同じ給料形態だと思ってもらえれば分かりやすいかと。

月給制ではありますが契約内容の時給欄には2500円となっているので、残業すると1.25倍になるので3125円になります。

では早速5月にいただいたお給料を公開です。(派遣で働いて過去最高金額)

労働時間(定時)残業合計総支給
147H3.75H150.75H361,719円

ふむ。時給が上がったインパクトが大きい。

先月の給料の内訳は定時勤務173Hの残業0で346,000円。(時給は2000円)

今月は給料の内訳は約151Hで361,719円(契約書記載の時給は2500円)

先月と比べて労働時間が22時間減りましたが、お給料は1万円以上は上がりました。

5月は残業10時間ぐらいしたと思うので6月にいただけるお給料は今までで1番もらえそうです。

派遣エンジニアについては下の記事をご覧ください。

インフラエンジニアの勤務体系(経験7ヶ月目)

雇用形態給料(月給制)勤務時間帯(定時)リモート
派遣35万円9時〜17時(7時間労働)あり

4月は入ったばかりだっだので出社して勤務していましたが、4月後半からリモート勤務が始まりました。

5月は全てフルリモートでした。

僕よりもずっと前から在籍している派遣社員の方の勤怠を見たら、

去年からずっとフルリモートをされていたので僕もフルリモートが今後も続くんじゃ無いかと思っています。

このご時世ですからね。(コロナ)

出社してもしなくても仕事内容は変わらないので個人的にリモート勤務ができるのはとても嬉しい。

インフラエンジニアの仕事内容(経験7ヶ月目)言える範囲で

今僕はサーバチームに所属していまして、チームが見ているサーバは全てクラウドで構築されています。

なのでフルリモートでも問題なく仕事ができるということになります。

ありがとうクラウド!

ちなみにクラウドサービスはAWSがメインです。

AWSについては下の記事をご覧ください。

サーバチームの仕事は基本的にはサーバの運用保守がメイン。

ただ新規でサーバを立てたいという依頼やサーバをAWSに移したりといった仕事もポツポツ入ってくる感じです。

僕は主にサーバの運用保守をメインに仕事をしています。

実際どんな仕事をしているの?って思う方もいると思うので僕が実際にしている仕事の一部をお伝えしていきます。(言える範囲)

実際の仕事内容

  1. ソフトフェアのインストール
  2. DB更新やデータ取得
  3. エラーログの調査
  4. ステージング環境を構築
  5. アクセス制限
  6. アカウント作成
  7. サーバを移設
  8. リダイレクト設定

では各業務について解説していきますね。

①:ソフトフェアのインストール

お客様から依頼があればサーバにソフトウェアをインストールしたりします。

サーバ=ホームページやwebサービスを提供しているコンピューターだと思ってもらえればOK。
ソフトウェア=コンピュータの機能を拡張してくれるものだと思ってもらえればOK。

ソフトウェアといっても色々あります。

例えばZabbixというソフトウェアをサーバにインストールすればデータを監視できるようになったり、(監視サーバ)

MySQLをサーバにインストールすればデータを保存し検索できるようになったりします。(データベースサーバ。DBサーバ)

有名どころで情報が多かったり、バージョンが更新されていたり、惰弱性の問題が少ないソフトウェアをインストールするのであれば仕事がしやすいです。

ただその逆のことがあると大変だということが今回初めて知りました。

ソフトウェアをインストールしたらサーバをリロードするのでその作業も少しビビります笑

サーバってサービスを提供しているコンピューターなのでサーバが止まってしまったらクレームに繋がるのでインフラの仕事は慎重すぎるのがちょうどいいと感じている。

初めての作業ばかりなのでこまめに確認していますね。

②:DB更新やデータ取得

お客様から依頼があったらデータベースから情報を取得して渡したり、データを追加したりもします。

DBサーバにログインしてSQLを実行すると、データベースから情報を取得したりデータを追加したりすることができます。

SQL=データベースの操作をする言語のこと

例えば、MysQLの場合はDBサーバにログインして、『show databases;』と実行すればデータベースの一覧が表示されます。

show databases; というデータベースに対しての命令文がSQL言語ということですね。

③:エラーログの調査

サーバに何かしら問題が起きるとサーバにログ(記録)が残ります。

エラーログの調査は、毎日サーバのログを出力していて、問題がありそうなメッセージを見つけたら調査して責任者に報告する業務です。

エラーレベルは下の表が参考になるかと。レベル0のemergが1番危険なメッセージでまだ見たことはないですが、一生見たくありません笑

スクロールできます
レベル:内容レベル名
0:致命的emerg
1:警戒alert
2:危機的crit
3:エラーerr
4:警告warning
5:通知notice
6:情報info
7:デバッグdebug

④:ステージング環境を構築

サイトやサービスが乗っかっている本番のサーバとは別に本番とほぼ同様のステージング環境も作るのが一般的みたいです。

ステージング環境は本番とほぼ同様なのはずなので、ステージング環境でうまく動作できれば本番でもうまくいくよね?的なもの。

逆もそうでステージング環境でうまく動作できなければ本番もうまくいくはずがないよね?という本番の前に正確にテストできるのがステージング環境の役割かと。

ただ今回関わった仕事はインフラ部分ではなく(インフラ部分と言ってもいいのかもしれないけれど)サイトやアプリ側のものを複製してサーバに乗っけて開発者がテストできる環境を作る仕事でした。

どういうことかというと、同じサーバに本番とステージング用のサイトやアプリが乗っかっていて開発者がステージング環境で新しい機能などを追加した時にうまく動作できれば本番にも同様の作業をするといった感じです。

ただ本番はすでに稼働しているのに、今までステージング環境がなかったのが謎なので今度聞いておかねば。

⑤:アクセス制限

サーバを立てて誰でもログインできると困るのでIP制限やBasic認証をかけたりしました。

IP制限=指定したIPアドレス以外はサーバにログインできない制限をかけること
Basic認証=サーバにアクセスした際にユーザー名とパスワードを入力しないとログインができない設定

IP制限やBasic認証はNginxやApacheの設定ファイルに記述して設定を行いました。

Basic認証だとユーザー名とパスワードを知っていたら誰でも入れてしまうのでIP制限の方が安全かなと。

Nginx=webサーバ用のソフトフェア
Apache=webサーバ用のソフトフェア
webサーバ=会社のホームページなど静的サイトを表示させてくれるサーバ

⑥:アカウント作成

SSHできるアカウントやファイルを転送したりできるSFTPアカウントを作成するお仕事。

SSH=暗号化の技術を用いて安全にリモート(離れたところ)からサーバにアクセスできる技術
SFTP=暗号化の技術を用いて安全にリモート(離れたところ)からサーバにファイルをアップロード、ダウンロードできる技術

rootアカウントと呼ばれるサーバに対してなんでも操作できちゃうアカウントは基本的に使わないです。

なのでサーバに対して操作できる範囲を限定したSSHアカウントやSFTPアカウンを作成してお客様に提供したりするお仕事ということになります。

⑦:サーバを移設

サーバのOSが古かったりなど理由は色々あると思いますが、古いサーバにおいてあるサイトやアプリを新しいサーバに移設する作業に関わりました。

移設先の新設されたサーバはすでに用意されていたので、古いサーバにおいてあるサイトやアプリを移設するお仕事。

古いサーバにおいてあるサイトやアプリを移設するにはいくつか方法があると思うのですが、この部分の説明は割愛します。

古いサーバにあるサイトやアプリを新しいサーバに移し終えたら、あとはドメインを切り替える作業があります。

ドメイン切り替えについて

(例)

例えば古いAサーバにはブログのサービスが乗っかっている。ドメイン(住所)は「infra-note.net」。

①新しいサーバBにブログサービスを移設。ただ移設を終えても「infra-note.net」にユーザーがアクセスしたら古いサーバAをユーザーは見にいくことになります。まだドメイン(住所)の情報を変更していないからですね。

例えば僕が今住んでいるマンションから新しい家を建てて引っ越しを終えても、市役所に行って住所変更しないと手紙はいつまでも元いたマンショに届いてしまいます。①はこれと同じことが起きているということです。

②infra-note.netというドメイン(住所)にアクセスしたら新しいサーバBにアクセスがいくように作業することをドメイン切り替えって言ったりします。

この作業は残念ながら見ているだけでした。また機会があると思うのでやってみたい。

「自分でインターネットにサイト公開したことがあるのでその仕事やりますよ!(でも忘れてるかもなので調べてわからない部分は質問するよ!)」とアピールします笑

⑧:リダイレクト設定

リダイレクト設定というのはユーザーがAのページにアクセスしたらBのページにアクセスするように設定を変更することです。

例えば僕が本を出版したとします(いきなり!笑)

うん、この例えだけで本が出版できそうになるぐらい話が長くなるのでこの例えはやめておきます。(じゃあ書くなというツッコミ。聞こえてますよ!)

例えばAのページをリニューアルしてBのページを作成したから、これまでと同様にAのページにアクセスしてくるユーザがいたらBのページに移動する設定をNginxの設定に書き込んでいました。

ではではこれでインフラ経験7ヶ月目の報告は終了。

サーバチームの中にはAWSのサービスを利用してサーバの設計をしたり構築したりする方がいるのでいつかその仕事にも関われるように頑張っていきます!

最近未経験から派遣エンジニアになった理由について記事にしました。

エンジニア未経験の方や、実務経験が浅い方は結構参考になる部分もあると思います。

Twitterにてブログの更新などもツイートしているので、気軽に絡んでください^^

ではまた!

記事内容が参考になったと感じた方!

@sho-infra-noteをメンションして、記事のURLを入れて感想ツイートをくれた方はもれなくRT or リプします!

この記事が気に入ったら
フォローしてね!

@sho-infra-noteをメンションして感想ツイートをくれた方はもれなくRT or リプします!
URLをコピーする
URLをコピーしました!
記事の内容
閉じる