Как сейчас проходят собеседования на golang разработчика? Что спрашивают?

Топы

1. pgAdmin;
2. Navicat;
3. DBeaver;
4. HeidiSQL;
5. Datagrip;
6. OmniDB;
7. Beekeeper Studio;
8. TablePlus;
9. QueryPie;
10. SQLGate;
11. Retool.

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

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

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

Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".

Gotcha — корректная конструкция системы, программы или языка программирования, которая работает, как описано, но, при этом, контринтуитивна и является причиной ошибок, поскольку её легко использовать неверно.

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

Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?

И ответ оказался довольно прост. Я просто очень вовремя прочёл несколько хороших статей о внутреннем устройстве структур данных в Go и прочих деталях реализации. И этого, вполне поверхностного на самом деле, знания было достаточно, чтобы выработать некоторую интуицию и избегать этих подводных камней.

# ss -s
Total: 15046 (kernel 16739)
TCP:   39306 (estab 11458, closed 25092, orphaned 110, synrecv 0, timewait 24929/0), ports 0

Transport Total     IP        IPv6
*	  16739     -         -        
RAW	  0         0         0        
UDP	  15        5         10       
TCP	  14214     1214      13000    
INET	  14229     1219      13010    
FRAG	  0         0         0        

Эта статья посвящена проблемам работы DNS в Kubernetes, с которыми столкнулась наша команда. Как оказалось, иногда проблема лежит гораздо глубже, чем кажется изначально.

Вступление

Всегда наступает момент, когда в уже отлаженную работу вмешиваются обстоятельства, заставляя нас что-то менять. Так и наша небольшая команда была вынуждена перенести все используемые приложения в Kubernetes. Причин было много, объективных и не очень, но история, собственно, не об этом.

Так как до этого Kubernetes никто активно не пользовал, кластер несколько раз пересоздавался, из-за чего качество работы перенесенных приложений оценить мы не успевали. И вот, после четвертого переноса, когда все основное шишки уже набиты, все контейнеры собраны и все деплойменты написаны, можно проанализировать проделанную работу и, наконец, перейти к другим задачам.

11 часов, начало рабочего дня. В системе мониторинга не хватает части сообщений от одного из приложений.

Unable to connect to the server: x509: certificate has expired or is not yet valid

Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.