Best practice

  • find you drive, you should be excited about what you are doing
  • do not apply to famous companies, a lot of people will try to apply to them, for huge companies you will be small person
  • find and use tools and methods that actually work in practice, these are not just trending topics on IT forums
  • teach in advance, search for vacancies and test each product, you will have no enough time for preparation
  • feel confidence about your infrastructure, notice you chief about suspicious by email, ask him to answer. Save this mail.
  • system which not monitored – doesn’t exist
  • do not use bash in sophisticate logic scripts, it even can’t plus to digits, use something like python, ruby etc…
  • it is very long to recover whole server from backup, so backup files and databases to another directory or another server, in case of some damage.
  • discuss projects in not interactive mode, you should mind it very carefully and slow.
  • separate services between VM and containers, they shouldn’t disturb each other. In case of recovery from backup you should restore service in appropriate  time.

Technical:

  • backup databases locally, if you need to restore DB, you can do it faster then restore whole VM from tape.
  • if possible, do not mount share, download file and process it.
  • analyze logs not only by count, but their types (in thousands of same lines you can find a couple of unique line which are the key of the problem)
  • if you’d like to avoid metrics mess in monitoring, monitor application level between servers.
  • microservices is for big companies, which have big department with different programmers Scala/Java/Python. Microservices is designed to connect different programmers groups.
  • cloud services (Amazon, Google, Rackspace)  are very expensive

Code:

  • do not create project from scratch, copy successful project to your task
  • code, without tests, is not clean. Robert Martin.
  • DRY

before release new service:

  • what can go wrong with that service?
  • this service should proceed running if something go wrong?
  • how can you upgrade service, which will doesn’t affect users?
  • thing about test cases?
  • which metrics should you monitor?
  • which tests should you considered successful?

Quotes:

  • “Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build,  and test.” Ray Ozzie, CTO, Microsoft Corporation
  • “system that cannot be verified should never be deployed.” Robert Martin.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>