Всем привет! Меня зовут Илья, я технический писатель компании QTIM. Сегодня хотелось бы немного поговорить о своей профессии. 

Данная работа не очень популярна на рынке IT в данный момент. Когда я рассказываю кому-то, кем я работаю, многие слышат впервые о такой должности и не понимают, чем я занимаюсь. Разумеется, это люди не из мира IT, хотя предположу, что и среди них не все слышали про тех. писателей. В отличие от других более популярных IT-специальностей, по которым представлено большое количество вакансий и различных обучающих курсов, по данному направлению вакансий на рынке мало, а курсов еще меньше, найти их довольно сложно. Когда я попытался узнать, какое обучение сейчас доступно для изучения и есть ли оно вообще, обнаружил, что такие курсы практически отсутствуют, либо дают лишь базовые знания, которых будет недостаточно для полноценной работы. Возможно, что-то хорошее на рынке есть, но мне, к сожалению, не удалось найти.

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

Для начала хотелось бы в двух словах рассказать о том, что это вообще за профессия такая. Если вкратце, то технический писатель - это сотрудник, который занимается написанием технической документации.

Писатели могут заниматься написанием следующих типов документации:

Уже разобрались в прошлой статье, когда микросервисы не нужны, сейчас рассмотрим обратную ситуацию.

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

Объективно оценить свой проект сложно, но начать можно с вопроса с капелькой синдрома самозванца «а вырос ли мой проект до микросервисов? как понять, что нужно переходить на них?»

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

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

Когда открываешь бизнес, сталкиваешься с этим навязчивым чувством, что надо сразу  все самое крутое, современное, Яндекс так делают, значит, и я могу. Плавали, знаем. Но меня лично очень отрезвило на старте количество затрат на все новомодные технологии.

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