Operating system updates for pet servers

Junio 26th, 2017| Opinión, Trucos y Tutoriales

In a small company with a small team handling few but solid products, a number
of spawned projects for customers, and fleets of cloud machines provisioned for
serving the former; automation is key, even though not always necessarily
silver bullet. True complete automation reached in all technology operations is
utopia, or fake. Do not ever trust such claims.

Any operating system update can break the software, or the operating system,
even the underlying server in extreme cases. If you still have not found the
case, you better start applying operating system updates.

Completely automated information delivery is a different and healthy thing, for
the most part. Everything reducing fog of war in the modern company is key to
success, and maybe not as much recommended as it should be, when compared to
the continuous integration and continuous delivery groupthink of the second
half of the 2010s; not writing about the justified advocacy of the first half.
Current team and collaboration web application madness is good. Proper
resources discovery policies are gold.

Of course the modern platform thinking and current business constraints forces
us to treat servers as cattle, as everybody else, and some the information am
giving will not apply to servers such as web, application, data base read
replica servers or under certain safe k failure conditions elements in a read
write data base cluster. All of these am referring jointly as the pack.

Think more of a server that is ultimately responsible for the complete build of
absolutely everything. Or maybe a temporary architectural single point of
failure for convenience. Or instead something not critical at all, maybe not
even critical enough to be in the build and server orchestration
configurations, like to be expired proceedings for expiring customers. Think
about the phased death of biicode. Few companies disappear from dusk till dawn,
fewer technology platforms, even fewer in the case of technology platforms
intending becoming a build toolchain component. Bear in mind every single
company is doomed to disappear or else being intervened or merged. I just long
not to be there already when it gets to happen.

The pack action by default is just bring up a fresh machine and wipe out the
previous. For each case meriting distinction from the pack, a proper balance
must be reached when deciding update patching policy, between reaction speed to
the dreadier menaces, platform stability guarantees, low traffic hours, if any,
and operator time and involvement in the assessed stages of the proceedings, if

It does not really matter the degree of operator involvement with patch
applying you could want to use, like it or not, either way you are going to
know what your mileage is needing, and you are going to do what is cheaper in
your mileage.

Proper information delivery procedures are, instead, a must go. It is actually
quite simple, have here a snippet for servers info delivery:

You get to have a proper server discovery procedure first to populate your
server portfolio. That gets up to you, out of the scope of this article.

$srv_portfolio GETS RESULT OF CALL TO $populate_srv_portfolio

FOR $server IN $srv_portfolio DO

  (*   '$type' is probably kind of an enumerated type, pun intended. *)
  $type GETS RESULT OF CALL TO $assess_type PASSING $server

      CALL TO $check_for_updates PASSING $server AND $type

(*   Here is where you do IRC instead of Slack,
 * for it is free so you won't get sold by. *)
CALL TO $deliver_msg

That is all. Keep it simple. Nice pride ’17, stay safe, and do not take
anything for granted. Please do the challenge if you already have not.


Archivado en: Opinión, Trucos y Tutoriales

Escribe un comentario

Los campos marcados con son requeridos.
La información sensible como el Email no será publicada