Пользователь
В этой статье мы продолжим тему дизайна сетей ЦОД. Мы уже поговорили про надежность, рассмотрели организацию кабельной инфраструктуры в ЦОД и теперь самое время перейти к рассмотрению вопросов управления и оптимизации трафика. Немаловажную роль в оптимизации трафика на логическом уровне играет построение кабельной инфраструктуры, поэтому далее будем предполагать, что рекомендации по физическому построению сети из предыдущей статьи выполнены.
В статье будет рассматриваться версия использования GNS3 внутри виртуальной машины VMware Workstation 16, используется дистрибутив Ubuntu c LXQt
Ссылка на установочный скрипт автора статьи.
Можете выполнить его с помощью
chmod +x ./gns3-install.sh
./gns3-install.sh.
Сегодня самыми распространенными курсами для начинающего системного администратора являются курсы академии Cisco. Они позволяют ознакомиться с популярными протоколами и понять базовые концепции защиты, настройки и построения различных сетей.
При прохождении курса, в конце почти каждой главы встречаются задания, выполненные в виде практических работ в Cisco Packet Tracer, и для новичка Packet Tracer довольно удобен, среди его плюсов:
• интуитивно понятный интерфейс
• низкие требования к железу
• возможность пользоваться функциями перемотки времени
• режим симуляции, в котором можно наглядно посмотреть путь каждого пакета и также проверить его содержимое.
Однако при глубоком изучении современных сетевых технологий c Packet Tracer возникают некоторые сложности, среди которых:
• поддержка только Cisco устройств
• баги с оборудованием на комплексных схемах, особенно при настройке STP у коммутаторов (часто приходится просто копировать схему, вставляя её рядом, и тогда она чудесным образом начинает работать)
• неполная командная среда, т.е. практически ничего, что не входит в рамки CCNA, на нём собрать не получится. Например, создание сценариев для автоматизации EEM недоступно, не все функции расширенных ACL доступны
• нет совместимости со старыми версиями. К примеру, версия 8.1.1 не совместима с 8.2.0, при этом я могу взять и открыть файл проекта на новой версии, нажать CTRL+C, зайти в старую версию и нажать CTRL+V, и тогда все заработает
У меня две новости. Хорошая и плохая. Начнём с хорошей: вы можете делать это лучше, тратя меньше времени. Что это? Надо, наверное, было начать с плохой: вы плохо планируете.
Ваши прогнозы регулярно не сбываются из-за штуки под названием ошибка планирования. И, нет, не переживайте, чаще всего проблема не в несовершенстве мира и не отсутствии хороших методов прогнозирования. Проблема в вас. Но вы не одиноки.
IT — это рынок, на котором ротация кадров немного отличается от любых других отраслей. На собеседованиях смотрят проекты в портфолио, изучают репозитории соискателей или просят написать код. Любые документы об образовании часто отходят на второй план.
Тем не менее, отрасль предлагает различные варианты платного обучения, экзаменов, сертификатов и дипломов. Поэтому важно научиться разбираться, на что стоит тратить время и деньги, а на что нет.
I Вступление
Современный рынок требует быстрых изменений в организации процесса производства товаров и услуг, но при этом сохраняя стабильность и качество сформировавшегося ранее уровня ведения бизнеса. Эти тенденции в свою очередь диктуют свои условия и на рынке производителей ИТ-продуктов.
В последнее время в ИТ-производстве все больше нарастает смещение акцентов с ИТ-проектов, результатом которого является Продукт, к ИТ-продукту, результатом которого является ценность для заказчика. Эта тенденция продвигает Agile инструменты, ориентированные на ИТ-производство в условиях изменяющихся требований, которые позволяют перебирать варианты возникновения ценности при создании ИТ-продукта. Но применение гибких методологий влечет за собой целый ряд ограничений, в первую очередь высокие финансовые затраты, в виду высокой неопределенности искомого результата.
Хотелось бы воспользоваться инструментом, позволяющим создавать пилотные решения, за короткий промежуток времени, при минимальных затратах, с высоким уровнем документирования самого процесса и производимого результата. Это должно позволить получить исчерпывающую информацию, для анализа создаваемой в процессе производства функциональности ИТ-продукта, и ее отклонения от желаемой.
Я уже публиковал статью, посвященную обзору подобных решений, с обсуждением их преимуществ и недостатков статья.
Но эта тема получила новый импульс после ухода с рынка РФ части игроков.
Обсуждению вопросов организации производства ИТ-продуктов и посвящена данная статья.
Это не единичный и не уникальный экземпляр, но один из самых больших, а может и самый большой. В начале прошлого века в Штатах была мода на подобные конструкции, многие из которых до сих пор выполняют свою функцию.
Под катом небольшая история про то, как 44 тонны стали с комплектом ноу-хау, которые прослужили 87 лет по своему прямому назначению и работоспособны по сей день.
Операционные системы присутствуют в жизни каждого человека, от мобильных устройств до настольных компьютеров и серверов, их роль и значение трудно переоценить. Многие из нас уже знакомы с ними на интуитивном уровне.
Цель данной статьи — разобраться в основах операционных систем. Мы рассмотрим то, что делает ОС достаточно функциональными и эффективными, поговорим об их истории и технологиях. Статья будет интересна новичкам, которым интересно разобраться в основах ОС.
В апреле 2023 года вышла новая LTS-версия Django Web Framework, одного из самых популярных фреймворков для веб-разработки на Python.
«Вышла новая версия! Почему вы до сих пор не перешли на неё?» — такой вопрос часто возникает у студентов, изучающих этот фреймворк на курсах программирования. Аналогичный вопрос можно услышать и от начинающего специалиста, который недавно приступил к выполнению своих обязанностей в качестве бэкенд-разработчика.
А стоит ли сейчас вообще начинать новый проект на Django или изучать этот фреймворк? В этой статье я, Евгений Бартенев, техлид и автор курса «Python-разработчик», помогу разобраться с этими и другими вопросами. Мы поговорим о разных типах релизов Django, посмотрим на главные изменения в новом и затронем основные аспекты, которые следует учитывать при обновлении версии Django в проекте.
Мы – команда DataOffice Ростелекома. Мы занимаемся всеми большими данными нашей большой компании. Собираем данные из сотен систем источников, внедряем современные технологии, создаем собственные продукты для работы с данными и, конечно, используем технологии искусственного интеллекта.
Для того, чтобы заниматься большими данными такой большой компании нам нужна большая команда. У нас команда больше 300 человек и все они занимаются разными проектами, работают с разными технологиями, но все любят данные и очень любознательные.
В предыдущих статьях мы рассмотрели архитектуру решения Apache Kafka, развернули продукт и разобрались с отправкой и получением сообщений. Можно было бы, конечно, дальше погрузиться в тему использования данного решения, но в Интернете есть множество различных публикаций с примерами использования Kafka для различных задач и различных сред разработки. Поэтому данная статья будет целиком и полностью посвящена такой важной теме, как обеспечение безопасности Apache Kafka.
По своему предназначению Kafka является посредником между различными системами при их обмене сообщениями. Для этого, как мы помним, есть топики и разделы. Но проблема заключается в том, что при стандартной настройке Kafka по умолчанию, любой пользователь или приложение может писать любые сообщения в любой топик, а также считывать данные из любых топиков. Естественно, для сколько-нибудь промышленного применения системы такой подход недопустим. Например, в случае, когда несколько приложений используют один и тот же кластер Kafka, или когда кластер используется в качестве облачного сервиса для сторонних приложений, ну и естественно, когда в Kafka начинает обрабатываться конфиденциальная информация.
В статье мы будем говорить о встроенных в Kafka механизмах защиты и не будем касаться использования каких-либо наложенных средств.
В 90% случаев разработка и бизнес сталкиваются с проблемами в общении при совместной оперативной и проектной работе. Это приводит к частому изменению технических заданий и принципов работы продуктов, влияет на сроки и рамки проектов. Сложности в общении приводят к тому, что айтишники и другие сотрудники не довольны результатами работы друг друга.
Почему разработчики и представители бизнеса испытывают трудности в коммуникации друг с другом? Какие инструменты могут помочь решить эту проблему? Как программистам и другим работникам эффективно работать над совместными проектами?
С помощью Apache Kafka мы в Авито гарантируем соблюдение контрактов публикуемых событий. Рассказываем, как мы переработали архитектуру и сделали работу с Kafka удобнее и надёжнее.
Мы можем пережить даже полный отказ дата-центра. Почему — тоже расскажем в этой статье.
Добрый день! Меня зовут Михаил Емельянов, недавно я опубликовал на «Хабре» небольшую статью с примерным путеводителем начинающего Python-разработчика. Пользуясь этим материалом как своего рода оглавлением книги, я написал первые четыре главы мини-учебника «Ядро планеты Python», где постарался коротко, но достаточно ёмко раскрыть специфику, удобство, красоту и силу этого прекрасного языка.
Оригинал учебника лежит на GitHub, вы вольны сколько угодно дополнять и переделывать его. Самое главное — учебник написан на Jupiter Notebook, а это значит, что вы можете интерактивно редактировать код, мгновенно добавляя новые сущности или проясняя непонятные моменты.
Итак, за основу организации работ по реализации Продукта мы приняли концепцию переработки Требований в итоговый функционал, который можно идентифицировать и измерить в целевом ИТ-продукте.
Статья для тех, кто испытывает трудности в прогнозировании времени, которое будет затрачено на выполнение задачи.
Раньше я сам был таким человеком.
И не мудрено - никто не рождается с навыком идеально точного планирования.
Сейчас я довольно точно, в некоторых случаях даже до минуты, могу оценить сколько времени займёт у меня выполнение той или иной задачи, что при прежних попытках планирования казалось чем то невозможным. Как мне это удалось? Делюсь в статье.
Существует замечательная теория, что все проблемы с хранением пользовательских данных в базах — это последствие отсутствия единых идентификаторов. Дескать, номер паспорта может меняться, ФИО может дублироваться у нескольких пользователей, а «внутренние» идентификационные номера в различных ведомствах могут не совпадать.
И стоит только провести массовую персонализацию (централизованное присвоение всем гражданам и негражданам специальных идентификаторов), как все проблемы будут решены и наступит цифровой рай.
Так оно или нет? Можно спорить, можно смотреть на опыт внедривших стран. Я же постараюсь описать типовые ошибки при проектировании и разработке систем, хранящих Единый Идентификатор.
Привет, меня зовут Павел Кардаш, я IT архитектор в «Магните». В этой статье хочу поделиться лучшими практиками в управлении мастер‑данными.