Привет, Хабр. Меня зовут Рустам. Я работаю в Ozon: админю Kubernetes и пишу на Go.

У нас очень много сервисов на Go — их количество исчисляется тысячами. Запускаются они внутри кластеров Kubernetes. А я плотно работаю с Kubernetes и заметил, что при запуске кода внутри Kubernetes для резолва одного адреса делается до десяти DNS-запросов. Это, конечно, влияет на производительность.

Я решил разобраться, как Go делает DNS-запросы. В результате мне удалось уменьшить их количество в наших проектах до одного-двух. Как у меня это получилось и можно ли использовать мой опыт в вашем проекте, я расскажу в статье.

Привет! Меня зовут Катя, я руководитель команды технических писателей в Ozon.

Недавно разбирала внутренние документы компании и поняла, что есть некоторая путаница в головах — не всегда понятно, что за документы должны быть в компании и кто их должен писать.

Листая страницы Хабра, поймал себя на мысли, что я воспринимаю Хабр  как новостную ленту в социальной сети. То есть как нечто, что прямого отношения лично ко мне не имеет и касается меня очень  косвенным путем. Нечто полуразвлекательное-полупознавательное.

Ну, судите сами. Вот примерный список тем, которые превалируют на Хабре.

1. Что там новенького  у Илона Петровича Маска.

2. Как с помощью Arduino, говна и палок сделать годный фаллоимитатор радиоприемник.

3. Как я ушел с прошлой работы, и как мне было там плохо.

4. Как я нашел свою текущую работу, и какая она крутая.

5. Как живется специалисту X в стране Y.

6. Какой путь нужно проделать фельдшеру из Ангарска, чтобы стать тестировщиком мобильных приложений в Ирландии.

7. Обсуждение новомодной платформы для веб-разработки, которая через 3 года станет старомодной.

8. Промываем косточки крупным компаниям.

9. Исторические экскурсы в IT/технологии/медицину.

10.   Реклама компаний.

11.   Мнения обо всем отвлеченном на свете.

12.   И т.д.

Все эти темы и все статьи – неплохие, интересные. Но я хотел бы другого.

На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.

Проблема, как мне кажется, связана с тем, что эффективность труда сотрудников отдела QA обратно пропорциональна количеству «срочных, внезапно возникающих» сложных задач. Назовём это «парадоксом немецкого сантехника», который получает зарплату, когда у него нет вызовов: чем меньше протечек и аварий на его участке, тем качественнее и эффективнее его работа. Но чем меньше у него вызовов, тем больше кажется со стороны, что он ничего не делает.

• Чем отличается большое приложение от маленького?
• Как меняется кодовая база и процессы?
• Как поймать тот момент, когда надо что-то менять?