DBとインフラ周りの権限について
在宅勤務のリソースを使わざる負えない状況にはいつかくると思うので次期システムの時に在宅勤務のエンジニアでも渡せる環境づくりが必要かと思います。
一時期オフショア開発などはやったけども、流れとしてはクラウドソーシングで会社単位よりも個人単位になっていく気がします。そういったときに簡単に仕事をどうわたすかを今試行錯誤しています。
なので権限をどこまで共有しどこまで制限するのかが重要になってきます。
プログラマーにはどうしても本番DBでないと確認が取れない事とかが出てきそうですが、できるだけ本番のDBを検証に素早く映せる環境を作ることが大切かと思います。
本番DBに触ることができるのはオフィスにいる人のみ
やっぱり在宅勤務者には触らせるのは危険かと思います。１年以上働いたら触らせるとかいう規定があってもいいかもしれないです。
クラウドのコンソールと本番サーバーのroot権限は社員の中でも一部にしておく
本番サーバーでの障害対応はログを見たりnginxの再起動が必要であったりすることが多いけども、それは全てsudoで権限付与させておけばいいかと思います。クラウドコンソールからサーバーの追加が必要になった時は都度その一部の人が対応しないといけない事になりそうですが、コアになればなるほどインフラ周りの仕事が増えていくのは仕方がないことですね。
本番サーバーのアカウントは別で作成するべき
同じアカウントでSSHキーを分けて行う運用も多いけども、本番ではやはり誰が何をどのファイルを変更したのかっていうログが大事なのでアカウントは都度作成、削除した方がいいかと思います。グループを同じにすればそこまで難しい話ではないかと思います。
本番サーバーに入れるという事は.envが見れるという事なのでDBに入れるという事、すなわち在宅勤務のプログラマーには本番サーバーにも入らせる事が出来ないという事になります。障害が起きた場合は、ログ見るなりはオフィスのスタッフが見てどのリリースが原因かを見て戻して作業をした人にリリースしなおしてもらうっていう作業になるかと思います。そうなると在宅勤務のエンジニアがスキルが高かったとしても本番に入れないので行動範囲が限られてしまいます。なので、2年間なのか、3ヶ月なのかわからないですがある一定の信頼を経て在宅のエンジニアにも本番に入れる権限を与えないといけない時がくるかも知れないです。
となるとなおさら本番DBから検証DBに半同期するような仕組みが必要になってくるという事になるかと思います。であれば多くのケースで「本番でしか検証できない」っていう事を防げるのかと思います。でも「本番でしか検証できない」って超あるあるの話ですが。。。
在宅勤務のエンジニアを募集しています。
登録日：
更新日：