- 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.
- 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
- do not create project from scratch, copy successful project to your task
- code, without tests, is not clean. Robert Martin.
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?
- “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.