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. Build infrastructure around monitoring, but not otherwise.
  • 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.
  • users/developers shouldn’t know hostnames or ip addresses of servers, only services domain names or alias ip addresses.
  • title should match content


  • do not mount production data on tests envs: you can benchmark your prod env, devs can delete/rewrite data
  • 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.
  • if app requests backend through balancer, setup firewall on backend and allow requests only from balancers


  • 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?


  • use EXPLAIN in MySQL
  • use slowlog
  • use transaction over multiple operations, it save disk utilisation
  • use indexes
  • use limit, it saves traffic
  • use cache


  • “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.

In general, if you go with your solution into production don’t put database in Docker.

One thought on “Best practice

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>