По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
О переходе в IT профессию не думал разве только тот, кто в IT сфере уже работает. Высокие зарплаты, постоянная удаленка, куча плюшек и битвы HR-ов за самый оригинальный подкат к айтишнику на LinkedIn. Насмотревшись на фотографии и рассказы друзей айтишников, все это заставляет многих подумать: а не пора ли сменить профессию? Если задумались - значит пора. А мы, в свою очередь, поможем разобраться, какие бывают айтишники и как вам войти в айти.
Говоря про айтишников, многие представляют себе программистов, их еще называют девелоперы (от английского developer) или разработчики. Но поверьте, айти не заканчивается на них, а скорее только начинается. Разновидностей программистов - как товаров на Amazon: frontend, backend, full-stack, веб-программисты, мобильные и десктоп разработчики, DevOps программисты и прочие.
Особенно важно разобраться с тремя первыми - фронт, бэк, и фуллстэк.
Понять разницу между фронтэнд и бэкэнд девелопером - ну очень просто. Фронтенд пишет все, что происходит в видимой зоне, а бэкенд - за видимой зоной. Сейчас разберемся на конкретных примерах:
Netflix: красивую картинку с палитрой интересных киношек, кнопки, слайдеры и все, что вы видите в видимой зоне - сделали фронты. Алгоритмы рекомендаций, авторизацию, списание денег с вашей карты, то есть биллинг, и другие компоненты на фоне - сделали бэкенд девелоперы. Когда в следующий раз будете реветь от рекомендаций мелодрамы, которая ранила вас прямо в сердечко - это бэки постарались.
Amazon: карточки товаров, категории, навигация, отзывы и прочая визуальщина - фронты. Передача на на фронт актуальных цен товаров, калькуляция условий доставки в ваш регион мешка с леденцами со вкусом корицы, механизм умного поиска - бэки.
А еще есть фуллстэк программисты - это те, кто умеют и бэк и фронт.
В среднем, чтобы стать фронтом, надо поучить HTML, CSS, JavaScript - это база, с которой уже можно верстать сайты. Но технологии не стоят на месте и сейчас зачастую обычного знания JavaScript бывает недостаточно, поскольку во многих местах используются различные фреймворки расширяющие функционал языка, такие как React, Angular или Vue.
Ну а поскольку разработчик всегда работает с командой, то нужно знать как работать с системами управления версиями, зачастую это Git и уметь работать с API, чтобы найти общий язык с бэкэнд.
Бэкенд девелоперу, очевидно, нужно знать один из языков программирования для бэка. Какой? Вам нужно определиться самому. Посмотрите вакансии, которые вас интересуют и поймите, что нужно в компании вашей мечты.
Самые известные и популярные языки это Java, Python, PHP, С, С#, С++, Ruby и Go. Их очень много, но не стоит отчаиваться глядя на их количество - изучив один язык и поняв принципы программирования, вы сможете легко перейти на другой язык.
Еще можно выделить мобильных разработчиков, которые делают приложения для iOS и Android - им нужно подучить Objective-C и Swift для iOS и Kotlin или Java для андроида.
Поскольку разработчики пишут код не в вакууме, а взаимодействуют с различными системами, то вам нужно знать про SQL и принципы работы с базами данных. И очень важно уметь работать с NoSQL - нереляционными базами. Если хочешь заниматься только базами то для этого даже есть отдельная профессия - администратор баз данных (DBA).
Если вы будете заниматься веб разработкой, то нужно знать про принципы работы HTTP и про модель OSI, про веб сервера, как минимум Apache и Nginx, как работают API, аутентификация, основы безопасности. Уф, ну кажется этого должно хватить для начала.
Идем дальше - тестировщики, а они же QA (Quality Assurance). Тестирование бывает ручное, а бывает автоматическое. Автоматизаторы, безусловно, ближе к программистам - им нужно разрабатывать алгоритмы, знать процессы разработки ПО и его тестирования.
В ручном тестировании - все немного попроще. Зачастую тестирование становится отправной точкой для карьеры будущего айтишника. Входной билет сюда чуть ниже, войти проще. Нужно знать классификацию тестирования, методы и инструменты, уметь создавать сценарии тестирования. Нужно базово понимать протокол HTTP и модель OSI, немного HTML и CSS. Хорошо бы уметь работать с командной строкой, знать SQL, принципы API чтобы гонять запросы в каком-нибудь клиенте типа Postman, знать инструменты автоматического тестирования, такие как Selenium или Sahi.
Уф, кажется, основные профессии, связанные напрямую с разработкой софта мы проговорили. Теперь, друг, давай разберемся с не менее крутой частью IT, где ощущается острейший дефицит кадров - это инфраструктурные айтишники.
Итак, сетевые инженеры - без них не “взлетит” ни одно приложение, сервис, сайт, платформа, да что угодно! Сетевики настраивают маршрутизацию трафика, управляют сетью и гарантируют взаимодействие айти - инфраструктуры с внешними сетями. Открывая Tinder, каждый свайп вправо генерирует запрос к серверам, который прилетает в дата - центр тиндера и маршрутизируется на нужный сервер - это как раз сетевик постарался.
Сетевик должен знать основы сетевых технологий - классической школой в этом плане являются технологии Cisco (а также Huawei, Juniper и Mikrotik), надо знать технологии виртуализации, уметь работать с операционными системами Linux и Windows Server, иметь представления о кибербезопасности и уметь читать и базово говорить по английски.
И конечно безопасники - про их востребованность сейчас, вы наверняка догадываетесь. Среди них выделяют:
Инженеров - эти ребята делают безопасной сеть, настраивают фаерволы, антивирусы, анти-DDoS, прокси и прочие средства защиты
Аналитиков - которые выявляют инциденты, мониторят и находят вредоносную активность, расследуют взломы, утечки и другие неприятные моменты
Пентестеров - это HackerMan’ы по найму. Ага, эти ребята занимаются легитимным взломом, чтобы потом вы могли закрыть все дырки обнаруженные ими и не стать жертвой настоящих хакеров
Консультантов - знают все законы и требования в ИБ, помогут в получении нужных бумаг, чтобы не попасть на штрафники от всяких регуляторов
Appsec, Cloudsec - занимаются безопасностью приложений и облачной инфраструктуры
В компаниях постоянно идут эпические битвы между айтишниками и ИБшниками, потому что последние, довольно параноидальные ребята. Они стараются максимально обезопасить инфраструктуру и её активы, вводя для этого различные правила. Например - хочешь подключиться к корпоративному VPN? Сначала пройди двухфакторную аутентификацию! Долго? Зато безопасно.
Для безопасника будет полезно понимать основы сетевой безопасности, а также операционных систем, знать что такое триада CIA и принцип Defense in Depth, ну и конечно же - знать какие существуют методы атак, вредоносного ПО и прочих ИБ угроз.
Так же есть более узкопрофильные направления - Linux или Windows администратор, специалист по IP - телефонии, администратор баз данных, SRE инженер и многие другие! Ну и конечно можно наоборот выделить широкопрофильного системного администратора - специалиста, который настраивает и поддерживает ИТ инфраструктуру компании и должен знать много вещей из разных областей.
Так, кажется большинство популярных технических направлений мы проговорили. Теперь давайте прыгнем к менеджерам, тем, кто управляет ИТ проектами и продуктами с точки зрения бизнеса. Вообще, скажем так, быть техно - коммерческим специалистом в айти отрасли ну крайне выгодно: комбинируя хороший технический бэкграунд, знание бизнес специфики, добавив высокие коммуникативные навыки и надев белую рубашку вы автоматически получаете высочайшую зарплату, корпоративную тачку и прочие радости. Ладно, шутка, давайте разбираться.
Продакт менеджеры (они же продакты) - эти ребята отвечают за коммерческий успех продукта и реализацию бизнес требований. Продакт знает такие фреймворки как Scrum и Agile, должен знать цикл разработки программного обеспечения, отвечать за список задач на разработку, который также называют “бэклог” и обязательно уметь говорить на одном языке с разработчиками, топ-менеджментом, продавцами, маркетингом и другими подразделениями компании. Пожалуй, продакт должен знать такие инструменты как JIRA, Trello, Miro, Slack и Wrike, и уметь анализировать метрики успеха продукта.
Если хотите двигаться в это направление, рекомендуем получить интересующие вас технические навыки, а потом двигать в бизнес плоскость - почитать Lean Startup, “Спросите маму” Роберта Фитцпатрика и про Scrum у Джеффа Сазерленда. Эти книги помогут вам базово сориентироваться в пространстве и получить базовое представление.
Проектные менеджеры, они же delivery менеджеры - они отвечают за реализацию проекта - контроль сроков, доставку функций продукта в продакшн, то есть в реальную среду работы продукта, отвечают за организацию человеческих ресурсов и планирование, в том числе релизов. Из хард скиллов вам надо знать что такое "Диаграмма Ганта", изучите свод знаний по управлению проектами PMBOK, который разработан американским Институтом управления проектами (PMI), знать гибкие методологии и уметь работать с теми же инструментами, что и продакту (JIRA, Trello, Miro, Slack и Wrike).
А еще есть UX - дизайнеры, продуктовые дизайнеры, аналитики, но они имеют менее технический уклон, чем продакты и проджекты.
Познать востреброванные айти профессии, получая знания в легкой и дружелюбной форме можно с помощью нашей платформы доступного айти образования Merion Academy: ознакомиться со списком курсов и пройти бесплатные вводные уроки можно по этой ссылке.
MPLS (Multiprotocol label switching) является протоколом для ускорения и формирования потоков сетевого трафика, что, по сути, означает сортировку MPLS и расстановку приоритетов в ваших пакетах данных на основе их класс обслуживания (например, IP-телефон, видео или данные Skype). При использовании протоколов MPLS доступная используемая пропускная способность увеличивается, а критически важные приложения, такие как передача голоса и видео, гарантируют 100% бесперебойную работу.
Как работает MPLS?
MPLS это метод маркировки пакетов, который устанавливает приоритетность данных. Большинство соединений сети должны анализировать каждый пакет данных на каждом маршрутизаторе, чтобы точно понимать его маршрут следования.
Виды маршрутизаторов
CE маршрутизатор, используемый со стороны узла клиента, который непосредственно подключается к маршрутизатору оператора.
CE взаимодействует с маршрутизатором со стороны оператора (PE) и обменивается маршрутами внутри PE. Используемый протокол маршрутизации может быть статическим или динамическим (протокол внутреннего шлюза, такой как OSPF, или протокол внешнего шлюза, такой как BGP).
Раскроем не понятные аббревиатуры - маршрутизатор Customer Edge (CE) подключается к маршрутизатору Provider Edge (PE).
PE маршрутизатор - граничный маршрутизатор со стороны оператора (MPLS домена), к которому подключаются устройства CE. Приставка PE к маршрутизатору, означает то, что он охватывает оборудование, способное к работе с широким диапазоном протоколов маршрутизации, в частности:
Протокол пограничного шлюза (BGP) (связь PE-PE или PE-CE);
Протокол динамической маршрутизации (OSPF) (связь между маршрутизатором и PE);
Многопротокольная коммутация по меткам (MPLS) (связь между маршрутизатором PE и P. Что такое P – маршутизатор поговорим дальше.);
Некоторые маршрутизаторы PE также выполняют маркировку трафика.
P - маршрутизатор - внутренний маршрутизатор сети оператора (провайдера) MPLS домена. В многопротокольной коммутации по меткам (MPLS) маршрутизатор P функционирует как транзитный маршрутизатор базовой сети. Маршрутизатор P обычно подключен к одному или нескольким маршрутизаторам PE.
Принципы работы MPLS
Входной маршрутизатор с MPLS (напомним, multiprotocol label switching, с английского) будет помечать пакеты данных при входе в сеть расставляя метки, поэтому, маршрутизаторы будут точно понимать, куда направляются данные, без необходимости снова и снова анализировать пакет с данными.
Чтобы понять принцип работы методики MPLS следует отметить, что в традиционной IP-сети каждому маршрутизатору приходится выполнять поиск IP, путем постоянного поиска его в таблицах с пакетами данных с последующей пересылкой на следующий уровень пока пакеты данных не достигнут нужного пункта назначения.
MPLS технология присваивает метку всем IP-пакетам, а тем временем уже сами маршрутизаторы принимают решение о передаче пакета далее на следующее устройство благодаря нужному значению метки. Метка добавляется в составе MPLS заголовка, который добавляется между заголовком кадра (второй уровень OSI) и заголовком пакета (третий уровень OSI) и, по сути, в дальнейшем идет их наложение друг на друга.
Хедер (заголовок) фрейма
MPLS хедер (заголовок)
Хедер (заголовок) IP пакета
IP пакет
Методика MPLS вместо этого выполняет "коммутацию меток", когда первое устройство выполняет поиск маршрутизации, как и прежде, но вместо поиска следующего перехода он находит конечный маршрутизатор назначения по заранее заданному маршруту. Маршрутизатор определяет метку на основе информации, которую будут использовать маршрутизаторы для дальнейшей маршрутизации трафика без необходимости каких-либо дополнительных поисков IP адресов, по достижению конечного маршрутизатора метка удаляется и пакет доставляется с помощью обычной IP маршрутизацией.
В чем преимущество переключения меток по методу MPLS?
Система меток значительно снижает время необходимое на поиск IP-маршрутизации.
Позволяет осуществлять точный поиск совпадений с самым длинным префиксом, что снижает ресурс обращения к памяти для маршрутизации одного пакета.
Точные совпадения на основе меток намного проще реализовать в оборудовании при меньшей нагрузке на него.
Дает возможность контролировать, где и как трафик распределен в сети, чтобы управлять пропускной способностью, расставлять приоритеты для различных сервисов и предотвращать перегрузку оборудования.
Для работы MPLS используют протоколы маршрутизации распространения меток (LDP), простой неограниченный протокол (без поддержки трафика), протокол резервирования ресурсов с проектированием трафика (RSVP-TE). На практике же обычно используют протокол распространения меток (LDP), однако протокол RSVP-TE необходим для функций организации трафика и в сложных сетях фактически не обойтись без этих двух протоколов с настройкой LDP для туннелирования внутри протокола RSVP.
Передача и управление трафиков происходит за счёт технологии Traffic Engineering, которая осуществляет передачу трафика по каналам по наиболее оптимальному маршруту, но с некоторыми ограничениями благодаря технологии CSPF (Constrained Shortest Path First), которая выбирает пути не только пользуясь критерием, основанном на его оптимальной длине маршрута, но еще и учитывает загрузку маршрутов. Используемые протоколы RSVP-TE позволяют резервировать полосы пропускания в сети.
Технология MPLS также имеет защиту от сбоев основываясь предварительном расчете путей резервного копирования для потенциальных сбоев канала или узла. При наличии сбоя в сети автоматически происходит расчет наилучшего пути, но при наличии одного сбоя расчет необходимого пути начинает происходить еще до обнаружения сбоя. Пути резервного копирования предварительно запрограммированы в FIB маршрутизатора в ожидании активации, которая может произойти в миллисекундах после обнаружения сбоя.
Можно выделить следующие преимущества организации VPN на базе MPLS
возможность масштабируемости трафика в широких пределах;
возможность пересечения адресных пространств, узлов подключенных в различные VPN;
изолирование трафика VPN друг от друга на втором уровне модели OSI.
В заключении следует отметить, что на практике MPLS в основном используется для пересылки единиц данных протокола IP (PDU, (Protocol Data Unit)) и трафика виртуальной частной локальной сети (VPLS) Ethernet. Основными приложениями MPLS являются инженерия телекоммуникационного трафика и MPLS VPN.
Давно прошли те времена, когда «база данных» представляла собой единую СУБД на основе реляционной модели данных, которую обычно устанавливали на самом мощном сервере в центре обработки данных. Такая база данных могла обслуживать все виду запросов – OLTP (On-Line Transaction Processing – обработка транзакций в режиме реального времени), OLAP (On-Line Analytical Processing – аналитическая обработка данных в режиме реального времени) – все, что нужно для бизнеса.
В настоящее время базы данных работают на самом обычном оборудовании, они также стали более сложными с точки зрения высокой доступности и более специализированными для обработки определенного типа трафика. Специализация позволяет добиться гораздо большей производительности баз данных – все оптимизировано для работы с определенным типом данных: оптимизатор, механизм хранения, даже язык может быть не SQL, как это бывает обычно. Он может быть основан на SQL с некоторыми расширениями, которые позволяют более эффективно манипулировать данными, или может быть чем-то абсолютно новым, созданным с нуля.
На сегодня мы имеем аналитические столбчатые базы данных, такие как ClickHouse или MariaDB AX, платформы обработки и анализа больших данных, такие как Hadoop, решения NoSQL, такие как MongoDB или Cassandra, хранилища данных типа «ключ-значение», такие как Redis. Мы также имеем базы данных временных рядов, такие как Prometheus или TimeScaleDB. Это именно то, на чем мы акцентируем внимание в данной статье. Базы данных временных рядов (Time Series Databases) – что это такое и зачем вам нужно еще одно хранилище данных в своей среде.
Для чего нужны базы данных временных рядов?
Как видно из названия, базы данных временных рядов предназначены для хранения данных, которые изменяются со временем. Это могут быть абсолютно любые данные, собранные с течением времени. Это могут быть метрические показатели, собранные из некоторых систем – все системы трендов являются примерами данных временных рядов.
Каждый раз, когда вы смотрите на информационные панели в ClusterControl, на самом деле вы видите визуальное представление временных рядов, хранящихся в Prometheus – базе данных временных рядов.
Временные ряды не ограничиваются метрическими показателями базы данных. Метриками может быть что угодно – изменение потока людей, входящих в торговый центр, с течением времени, изменение трафика в городе, использование общественного транспорта в течение дня, течение воды в реке или ручье, количество энергии, вырабатываемое водной установкой – все это и все остальное, что можно измерить во времени, является примером временных рядов. Такие данные можно запросить, построить, проанализировать, чтобы найти корреляционную зависимость между различными метриками.
Структура данных в базе данных временных рядов
Как вы понимаете, самая важная составляющая данных в базе данных временных рядов – это время. Существует два основных способа хранения данных. Первый способ чем-то похож на хранилище «ключ-значение» и выглядит так:
Метка времени
Метрика 1
2019-03-28 00:00:01
2356
2019-03-28 00:00:02
6874
2019-03-28 00:00:03
3245
2019-03-28 00:00:04
2340
Проще говоря, для каждой метки времени имеется некоторое значение метрики.
Второй способ подразумевает хранения большего числа показателей. Вместо того, чтобы хранить каждую метрику в отдельной таблице или коллекции, их можно хранить вместе.
Метка времени
Метрика 1
Метрика 2
Метрика 3
Метрика 4
Метрика 5
2019-03-28 00:00:01
765
873
124
98
0
2019-03-28 00:00:02
5876
765
872
7864
634
2019-03-28 00:00:03
234
7679
98
65
34
2019-03-28 00:00:04
345
3
598
0
7345
Такая структура данных, когда все метрики связаны, позволяет более эффективно запрашивать данные. Вместо того, чтобы читать несколько таблиц и объединять их для получения всех метрик, достаточно прочитать лишь одну единственную таблицу, чтобы подготовить данные к обработке и представлению.
У вас может возникнуть вопрос – что же здесь нового? Чем эта база данных отличается от обычной таблицы в MySQL или в любой другой реляционной базе данных? Да, действительно, конструкция таблиц очень похожа. Однако есть существенные различия в рабочей нагрузке, которые могут существенно повысить производительность, если хранилище данных предназначено для использования такого рода таблиц,
Временные ряды, как правило, только растут. Маловероятно, что вы будете обновлять старые данные. Чаще всего строки в таблице не удаляются, однако вам может понадобиться какая-то агрегация данных с течением времени. Если принять это при проектировании внутреннего устройства базы данных, то этот факт будет иметь существенное расхождение в сравнении со «стандартными» реляционными (и не реляционными) базами данных, предназначенными для обработки транзакций в режиме реального времени. Что здесь является наиболее важным, так это способность последовательно хранить большие объемы данных, поступающих со временем.
Можно, конечно, использовать РСУБД для хранения временных рядов, но она не оптимизирована для этого. Данные и индексы, сгенерированные на ее основе, могут стать слишком большими, и запросы будут проходить очень медленно. Механизмы хранения данных, используемые в СУБД, предназначены для хранения различных типов данных. Обычно они оптимизированы для рабочей нагрузки обработки транзакций в режиме реального времени, которая включает в себя частое изменение и удаление данных. В реляционных базах данных также часто отсутствуют специализированные функции и функции, предназначенные для обработки временных рядов. Мы уже упоминали, что вы вероятно столкнетесь с необходимостью агрегировать данные, полученные ранее какой-то временной метки. Вы также можете иметь возможность легко запускать некоторые статистические функции для ваших временных рядов, чтобы сглаживать их, определять и сравнивать тренды, интерполировать данные и многое другое. Здесь, например, вы можете найти некоторые функции, которые Prometheus предоставляет пользователям.
Примеры баз данных временных рядов
На рынке существует множество баз данных временных рядов, поэтому, естественно, что рассмотреть все мы не сможем. Но мы все же хотели привести несколько примеров баз данных временных рядов, которые, возможно, вам уже знакомы или которые вы уже, возможно, используете (сознательно или нет).
InfluxDB
InfluxDB была разработана компанией InfluxData. Это база данных временных рядов с открытым исходным кодом, написанная языке программирования Go. Хранилище данных позволяет вводить запросы данных на языке, подобном SQL, что позволяет разработчикам легко интегрировать эту базу данных в свои приложения. InfluxDB также может работать как часть коммерческого решения, которое охватывает весь стек, предназначенный для обеспечения процесса обработки данных временных рядов, полнофункциональной высоко доступной средой.
Prometheus
Prometheus – это еще один проект с отрытым исходным кодом, который также написан на языке программирования Go. Он обычно используется в качестве серверной части для различных инструментов и проектов с открытым исходным кодом, например, Percona Monitoring and Management. Prometheus также является наилучшим вариантом для ClusterControl.
Prometheus можно развернуть из ClusterControl с целью хранения данных временных рядов, собранных на серверах баз данных, контролируемых и управляемых ClusterControl:
Prometheus широко используется в мире Open Source, поэтому его довольно легко интегрировать в уже существующую среду с помощью нескольких экспортеров.
RRDtool
Это один из примеров базы данных временных рядов, которую многие используют, даже не подозревая об этом. RRDtool – это достаточно популярный проект с открытым исходным кодом для хранения и визуализации временных рядов. Если вы хоть раз использовали Cacti, то и RRDtool вы тоже использовали. Если вы разработали свое собственное решение, вполне вероятно, что и здесь вы тоже использовали RRDtool в качестве серверной части для хранения данных. Сейчас RRDtool, возможно, не так популярен, как это было в 2000-2010 годах. В те годы это был самый распространенный способ хранения временных рядов. Забавный факт – ранние версии ClusterControl использовали именно RRDtool.
TimeScale
TineScale – это база данных временных рядов, разработанная на основе PostgreSQL. Это расширение для PostgreSQL, которое использует основное хранилище данных для предоставления доступа к ним, что означает, что оно поддерживает все разновидности SQL, доступные для использования. Поскольку это расширение, то оно использует все функции и расширения PostgreSQL. Вы можете совмещать временные ряды с другими типами данных, например, объединять временные ряды с метаданными, пополняя информацией выходные данные. Вы также можете выполнить более сложную фильтрацию, используя JOIN и таблицы без временных рядов. Геоинформационное обеспечение в PostgreSQL TimeScale можно использовать для отслеживания географических местоположений с течением времени, а также использовать все возможности масштабирования, предлагаемые PostgreSQL, включая репликацию.
Timestream
Amazon Web Services также предлагает базы данных временных рядов. О Timestream было объявлено совсем недавно, в ноябре 2018 года. Она добавляет еще одно хранилище данных в портфель AWS, помогая пользователям обрабатывать временные ряды, поступающие из таких источников, как устройства Интернет вещей или отслеживаемые сервисы. Его также можно использовать для хранения метрических данных, полученных из журналов, созданных несколькими службами. Это позволяет пользователям выполнять аналитические запросы к ним, помогая понять закономерности и условия, в которых работают службы.
Tiemstream, как и большинство сервисов AWS, обеспечивает простой способ масштабирования в случае, если с течением времени возрастает потребность в хранении и анализе данных.
Как видите, вариантов баз данных временных рядов на рынке множество, и это не удивительно. В последнее время, все более популярным становится анализ временных рядов, поскольку он становится все более важных для различных бизнес-операций. К счастью, есть большое количество проектов как с открытым кодом, так и коммерческих. И с большой долей вероятности вы сможете найти инструмент, который полностью удовлетворит ваши потребности.